Jak zainstalować ModSecurity 2 z Apache na Debianie 12 lub 11

ModSecurity 2 to niezbędna zapora sieciowa aplikacji internetowych (WAF) do zabezpieczania serwerów Apache HTTP, oferująca monitorowanie w czasie rzeczywistym i filtrowanie oparte na regułach. Zainstalowana na serwerze Linux Debian 12 lub 11, ModSecurity pomaga zapobiegać wstrzyknięciom SQL, cross-site scripting (XSS) i innym atakom. Repozytorium Digitalwave ModSecurity upraszcza instalację, zapewniając korzystanie z najnowszej stabilnej wersji.

Aby zwiększyć bezpieczeństwo, OWASP Core Rule Set (CRS) udostępnia wstępnie skonfigurowane reguły ukierunkowane na typowe luki w zabezpieczeniach. Jego skonfigurowanie pozwala administratorom wzmocnić obronę przy minimalnej ręcznej konfiguracji. Ten przewodnik pokaże Ci, jak zainstalować ModSecurity 2 na Debianie przy użyciu repozytorium Digitalwave i skonfigurować OWASP CRS w celu zapewnienia optymalnej ochrony.

Aktualizacja pakietów systemu Debian w celu instalacji ModSecurity 2

Pierwszym krokiem jest upewnienie się, że nasz system Debian jest aktualizowany. Dzięki temu wszystkie istniejące pakiety będą aktualne, zapewniona zostanie optymalna wydajność i zminimalizowane zostaną zagrożenia bezpieczeństwa. Można to osiągnąć, uruchamiając następujące polecenie:

sudo apt update && sudo apt upgrade

Po zaktualizowaniu systemu sprawdź, czy Apache jest zainstalowany. Jeśli nie, użyj następującego polecenia, aby go zainstalować:

sudo apt install apache2

Importuj moduł ModSecurity PPA

Konfigurowanie wymaganego repozytorium

Następnym zadaniem na naszej liście jest instalacja modułu ModSecurity Apache. Wersja dostępna w domyślnych repozytoriach Debiana może nie być najnowsza, a jej użycie może prowadzić do natychmiastowych błędów. Zamiast tego zaimportujemy repozytorium innej firmy, aby zainstalować najnowszy moduł ModSecurity dla Apache. To repozytorium innej firmy, utrzymywane przez Digitalwave, jest znane ze swoich stabilnych plików binarnych.

Zacznij od zainstalowania zestawu niezbędnych pakietów:

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

Następnie importujemy repozytorium modułu PPA ModSecurity 2 Klucz GPG:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null

Po uzyskaniu klucza GPG dodaj repozytorium do swojego systemu:

echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list

Nadawanie priorytetu nowemu repozytorium PPA modułu Apache

Mając repozytorium na miejscu, teraz konieczne jest dostosowanie polityki APT, aby nadać priorytet temu repozytorium dla określonych pakietów związanych z ModSecurity. Poniższe polecenie to realizuje:

cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

Następnie uruchom aktualizację APT, aby uwzględnić nowo zaimportowane źródło:

sudo apt update

Dodatkowo, aby potwierdzić preferencje, możesz potwierdzić zmianę tej polityki w następujący sposób:

sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3

Zainstaluj moduł ModSecurity 2

Teraz, gdy repozytorium jest gotowe, kontynuuj instalację modułu libapache2-mod-security2:

sudo apt install libapache2-mod-security2

Po instalacji moduł musi zostać włączony. Użyj następującego polecenia, aby to osiągnąć:

sudo a2enmod security2

Ponowne uruchamianie usługi Apache

Na koniec ponownie uruchamiamy usługę Apache, aby upewnić się, że wszystkie zmiany zostaną zastosowane, a nowo dodany moduł ModSecurity jest poprawnie zintegrowany:

sudo nano /etc/apache2/mods-enabled/security2.conf

Włącz moduł ModSecurity 2 na Apache HTTP

Uzyskiwanie dostępu do pliku konfiguracyjnego ModSecurity

Plik konfiguracyjny dla Apache ModSecurity można znaleźć w /etc/apache2/mods-enabled/security2.conf. Dostęp do tego pliku można uzyskać za pomocą edytora tekstu nano (lub preferowanego edytora tekstu) za pomocą następującego polecenia:

sudo nano /etc/apache2/mods-enabled/security2.conf

Poszukaj wiersza, który brzmi:

IncludeOptional /etc/modsecurity/*.conf

Upewnij się, że ten wiersz jest niezakomentowany, ponieważ zawiera inne niezbędne pliki konfiguracyjne z katalogu /etc/modsecurity. Domyślnie powinien być niezakomentowany.

Modyfikowanie konfiguracji ModSecurity 2

Musimy zmienić nazwę pliku konfiguracyjnego modsecurity.conf-recommended na modsecurity.conf, aby go uaktywnić. Można to zrobić za pomocą następującego polecenia:

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Teraz otwórzmy ten nowo nazwany plik konfiguracyjny:

sudo nano /etc/modsecurity/modsecurity.conf

Silnik reguł ModSecurity jest domyślnie ustawiony na DetectionOnly w tym pliku. Oznacza to, że będzie identyfikował i rejestrował potencjalnie złośliwe zachowanie bez blokowania go. Aby to zmienić i włączyć możliwości blokowania ModSecurity, znajdź wiersz SecRuleEngine (w pobliżu wiersza 7) i zamień DetectionOnly na On.

Z:

SecRuleEngine DetectionOnly

Do:

SecRuleEngine On

Dostosowywanie ustawień dziennika dla Apache

Dalej w pliku konfiguracyjnym znajdziesz linię SecAuditLogParts (około linii 224). Domyślne ustawienie tej linii nie jest do końca poprawne; należy je dostosować, aby dokładnie rejestrować wszystkie informacje o transakcjach.

Zmiana:

SecAuditLogParts ABDEFHIJZ

Do:

SecAuditLogParts ABCEFHJKZ

Po wprowadzeniu zmian zapisz je i wyjdź z edytora.

Ponowne uruchomienie Apache w celu zastosowania zmian

Ostatnim krokiem w tym procesie jest ponowne uruchomienie usługi Apache, aby zmiany w konfiguracji ModSecurity zostały wprowadzone. Można to zrobić za pomocą następującego polecenia:

sudo systemctl restart apache2

Zainstaluj zestaw podstawowych reguł OWASP dla ModSecurity2

ModSecurity samo w sobie nie zabezpiecza serwera WWW. Wymaga zestawu reguł, aby identyfikować potencjalne zagrożenia i blokować złośliwą aktywność. Zestaw podstawowych reguł (CRS) OWASP (Open Web Application Security Project) jest wysoko cenionym zestawem reguł używanym przez różne serwery WWW i zapory sieciowe aplikacji internetowych (WAF). Wdrożenie tego zestawu reguł zapewnia serwerowi solidną ochronę przed szeregiem zagrożeń pojawiających się w Internecie.

Zanim przejdziemy dalej, koniecznie sprawdź, czy posiadasz najnowszą wersję OWASP CRS, odwiedzając stronę Strona znacznika wydania OWASPTen krok zapewnia pobranie i zainstalowanie najnowszych środków bezpieczeństwa dla Twojego serwera.

Tworzenie katalogu nadrzędnego dla OWASP CRS

Najpierw utwórzmy wiodący katalog nadrzędny dla OWASP za pomocą polecenia mkdir:

sudo mkdir /etc/apache2/modsec/

Pobierz archiwum OWASP CRS na Debianie

Następnie użyjemy polecenia wget, aby pobrać archiwum OWASP CRS 3.3.4, które jest stabilną wersją w momencie pisania. Pamiętaj, że powinieneś zweryfikować wersję, korzystając z linku podanego wcześniej.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip

Nightly build może oferować bardziej aktualne środki bezpieczeństwa, ale może powodować problemy ze względu na swój status rozwoju. Nowym użytkownikom zaleca się korzystanie ze stabilnej wersji, aby uniknąć potencjalnych komplikacji.

Uwaga: Należy regularnie sprawdzać dostępność aktualizacji. Zasady nie zmieniają się co tydzień, lecz co kwartał lub w przypadku, gdy wymagana jest pilna aktualizacja.

Wypakowywanie archiwum

Po pobraniu archiwum możemy je rozpakować do wcześniej utworzonego katalogu:

sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec

Pamiętaj, aby zmienić polecenia na podstawie pobranej wersji OWASP CRS.

Konfigurowanie zestawu reguł

OWASP CRS ma przykładowy plik konfiguracyjny, którego nazwę należy zmienić, zachowując oryginał jako kopię zapasową. Można to zrobić za pomocą polecenia „cp”:

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Uwaga: Pamiętaj, aby zastąpić /coreruleset-3.3.4/ dokładną wersją OWASP CRS, którą wybrałeś.

Włączanie reguł

Aby aktywować reguły, otwórz plik /etc/apache2/mods-enabled/security2.conf:

sudo apt install unzip -y

Następnie wstaw następujące dwa wiersze:

Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf

Uwaga: Pamiętaj, aby zastąpić /coreruleset-3.3.4/ dokładną wersją OWASP CRS, którą wybrałeś, ponieważ coreruleset, który pobierzesz, będzie najprawdopodobniej nowszy niż przykład w przewodniku.

Dodatkowo zakomentuj lub usuń następujący wiersz:

IncludeOptional /usr/share/modsecurity-crs/*.load

Po wykonaniu tej czynności zapisz i wyjdź z pliku:

Ponowne uruchomienie Apache w celu zastosowania zmian

Ostatnim krokiem jest ponowne uruchomienie usługi Apache, aby upewnić się, że zmiany zostaną wprowadzone:

sudo systemctl restart apache2

Wprowadzenie do zestawu reguł podstawowych OWASP i ModSecurity 2

OWASP Core Rule Set (CRS) to kompleksowe narzędzie z wieloma konfigurowalnymi opcjami. Jego domyślna konfiguracja zapewnia natychmiastowe ulepszenia bezpieczeństwa dla większości serwerów bez wpływu na prawdziwych odwiedzających lub boty SEO (Search Engine Optimization). W tej sekcji omówimy kilka istotnych aspektów CRS, ale zawsze korzystne jest zbadanie plików konfiguracyjnych w celu pełnego zrozumienia wszystkich dostępnych opcji.

Dostosowywanie konfiguracji CRS

Zaczynamy od otwarcia pliku crs-setup.conf, w którym można zmienić większość ustawień CRS:

sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Zrozumienie systemu punktacji CRS

ModSecurity działa w dwóch odrębnych trybach:

• Tryb punktacji anomalii: Zalecany dla większości użytkowników, ten tryb przypisuje „punktację anomalii” za każdym razem, gdy reguła pasuje. Po przetworzeniu reguł przychodzących i wychodzących, punktacja anomalii jest sprawdzana, a w razie potrzeby uruchamiane jest działanie zakłócające. Działanie to często przyjmuje formę błędu 403. Ten tryb zapewnia dokładne informacje w dzienniku i oferuje większą elastyczność w ustawianiu zasad blokowania.
• Tryb samowystarczalny: W tym trybie akcja jest stosowana natychmiast, gdy tylko reguła zostanie dopasowana. Chociaż może zmniejszyć wykorzystanie zasobów, oferuje mniejszą elastyczność i generuje mniej informacyjne dzienniki audytu. Proces dopasowywania reguł zatrzymuje się, gdy pierwsza reguła zostanie spełniona i określona akcja zostanie wykonana.

Zrozumienie poziomów paranoi

OWASP CRS definiuje cztery poziomy paranoi:

• Poziom paranoi 1: Poziom domyślny jest odpowiedni dla większości użytkowników.
• Paranoja Poziom 2: Dla zaawansowanych użytkowników.
• Poziom paranoi 3: dla użytkowników zaawansowanych.
• Poziom paranoi 4: Zalecany wyłącznie w wyjątkowych okolicznościach.

Wyższe poziomy paranoi umożliwiają dodatkowe reguły, zwiększają bezpieczeństwo i zwiększają prawdopodobieństwo blokowania legalnego ruchu z powodu fałszywych alarmów. Wybór poziomu paranoi, który jest zgodny z Twoją wiedzą specjalistyczną i potrzebami bezpieczeństwa, jest niezbędny.

Testowanie OWASP CRS na Twoim serwerze

Aby upewnić się, że OWASP CRS działa poprawnie na Twoim serwerze, użyj przeglądarki internetowej, aby uzyskać dostęp do następującego adresu URL. Pamiętaj, aby zastąpić „twojadomena.com” swoją rzeczywistą domeną:

https://www.yourdomain.com/index.html?exec=/bin/bash

Jeśli otrzymasz błąd 403 Forbidden, OWASP CRS będzie działać zgodnie z oczekiwaniami. Jeśli nie, może to oznaczać błąd w procesie konfiguracji, który wymaga Twojej uwagi; najczęstszym problemem może być zapomnienie o zmianie DetectionOnly na On lub coś podobnego.

Rozwiązywanie problemów z fałszywymi wynikami pozytywnymi i regułami wykluczeń niestandardowych

Zarządzanie fałszywymi alarmami za pomocą ModSecurity i OWASP Core Rule Set (CRS) może być zadaniem ciągłym. Jednak solidna obrona, jaką te systemy oferują przed szeroką gamą zagrożeń, sprawia, że ​​wysiłek ten jest niezbędny. Aby zminimalizować fałszywe alarmy na początku, zaleca się ustawienie niskiego poziomu paranoi.

Uruchamiając zestaw reguł na niższym poziomie paranoi przez kilka tygodni lub nawet miesięcy, możesz zmniejszyć prawdopodobieństwo przytłaczającej liczby fałszywych wyników pozytywnych. To podejście daje Ci czas na zapoznanie się z alertami i odpowiednimi odpowiedziami przed stopniowym zwiększaniem poziomu paranoi w celu zapewnienia bardziej rygorystycznego bezpieczeństwa.

Zarządzanie fałszywymi alarmami w znanych aplikacjach na Debianie za pomocą OWASP, ModSecurity 2

ModSecurity obejmuje możliwość umieszczenia na białej liście pewnych działań, które mogą nieumyślnie wywołać fałszywe alarmy. Na przykład:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

Aby wprowadzić białą listę dla aplikacji takich jak WordPress, phpBB i phpMyAdmin, usuń komentarz z odpowiednich wierszy i zachowaj wartość (1). Aby zapobiec białej liście usług, które nie są używane, dostosuj wartość do (0).

Zaktualizowana konfiguracja może wyglądać następująco:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

W tym przypadku usunięto zbędne opcje, pozostawiając poprawną składnię dla wymaganych konfiguracji.

Tworzenie wykluczeń reguł przed wdrożeniem CRS

Aby utworzyć niestandardowe wykluczenia, zacznij od zmiany nazwy pliku „REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf” za pomocą następującego polecenia:

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Pamiętaj, że każda reguła wykluczania musi mieć unikalny „numer identyfikacyjny”, aby uniknąć błędów podczas testowania usługi Apache2.

Na przykład niektóre „REQUEST_URIs” mogą powodować fałszywe pozytywy. Poniższy przykład ilustruje dwa takie przypadki z udziałem Google PageSpeed ​​beacon i wtyczki WPMU DEV dla WordPressa:

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

Reguły te automatycznie zezwalają na wszystkie adresy URL zaczynające się od określonej ścieżki.

Możesz również dodać określone adresy IP do białej listy:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

W pierwszej regule pojedynczy adres IP jest umieszczany na białej liście, podczas gdy druga reguła używa dyrektywy „@ipMatch” do szerszego dopasowania podsieci. Aby zablokować podsieć lub adres IP, po prostu zamień „allow” na „deny”. Ta elastyczność pozwala na tworzenie szczegółowych czarnych i białych list, które można zintegrować z Fail2Ban w celu zwiększenia strategii bezpieczeństwa.

Wyłączanie określonych reguł w systemie Debian za pomocą OWASP, ModSecurity 2

Zamiast umieszczania całej ścieżki na białej liście, innym podejściem jest wyłączenie określonych reguł, które powodują uporczywe fałszywe pozytywy. Chociaż ta metoda wymaga więcej testów, oferuje długoterminowe korzyści.

Na przykład, jeśli reguły 941000 i 942999 w obszarze „/admin/” wyzwalają fałszywe alarmy dla Twojego zespołu, możesz znaleźć identyfikator reguły w dziennikach ModSecurity i wyłączyć tylko te konkretne identyfikatory, używając polecenia „RemoveByID”:

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Monitorowanie dzienników i identyfikacja wzorców

Ciągły monitoring dziennika jest niezbędny podczas obsługi fałszywych alarmów w Apache, ModSecurity i OWASP. Pomaga identyfikować wzorce, które wyzwalają fałszywe alarmy, umożliwiając tworzenie niestandardowych reguł w celu ich rozwiązania.

Na przykład, jeśli konkretne reguły stale powodują fałszywe pozytywy, możesz stworzyć regułę wykluczenia, aby poradzić sobie z tymi konkretnymi przypadkami. To dostosowane podejście zapewnia skuteczniejsze zarządzanie fałszywymi pozytywami.

Regularne przeglądanie dzienników i dostosowywanie reguł pozwala utrzymać bezpieczniejsze i wydajniejsze środowisko dla aplikacji.

Rotacja dziennika dla ModSecurity 2

Ze względu na dynamiczną naturę transakcji internetowych, dzienniki ModSecurity mogą szybko rosnąć, co sprawia, że ​​skuteczne zarządzanie dziennikami jest kluczowe. Rotacja dzienników jest przydatnym narzędziem do zarządzania tymi dziennikami, chociaż nie jest domyślnie skonfigurowana w ModSecurity. Ta sekcja przeprowadzi Cię przez konfigurację rotacji dzienników specjalnie dla ModSecurity.

Tworzenie pliku rotacji ModSecurity

Najpierw musisz utworzyć dedykowany plik do rotacji dziennika ModSecurity. Aby to zrobić, użyj następującego polecenia, aby utworzyć i otworzyć nowy plik o nazwie modsec:

sudo nano /etc/logrotate.d/modsec

Konfigurowanie pliku rotacji

W nowo utworzonym pliku konfiguracyjnym ModSecurity (modsec) dodaj następujące elementy:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

Ta konfiguracja przechowuje logi przez 31 dni, ale możesz zmienić liczbę, aby dopasować ją do swoich potrzeb. Na przykład zmiana na „rotate 7” spowoduje przechowywanie dzienników z tygodnia.

Dyrektywa „daily” zapewnia, że ​​logi są rotowane każdego dnia, podczas gdy „compress” oszczędza miejsce, kompresując stare logi. Opcja „delaycompress” opóźnia kompresję do drugiego cyklu rotacji, a „missingok” zapobiega błędom, jeśli plik dziennika jest nieobecny. Ponadto „notifempty” zapewnia, że ​​puste pliki dziennika nie są rotowane.

Wskazówka: Zaleca się codzienną rotację dzienników, aby uniknąć konieczności pracy z dużymi plikami dzienników, które mogą wydłużać czas analizy.

Wniosek

Zainstalowałeś ModSecurity 2 na serwerze Debian 12 lub 11 przy użyciu repozytorium Digitalwave i skonfigurowałeś OWASP Core Rule Set. Dzięki tym narzędziom serwer jest wyposażony w możliwość blokowania wielu powszechnych zagrożeń dla aplikacji internetowych.

Pamiętaj, aby regularnie aktualizować CRS i monitorować wszelkie fałszywe alarmy lub pominięte luki. Spójne testowanie i dostosowywanie są kluczowe dla utrzymania solidnej konfiguracji zabezpieczeń.