IDS

IDS (intrusion detection system) to system, który monitoruje ruch sieciowy albo aktywność na serwerze i zgłasza alert, gdy rozpozna podejrzany wzorzec. Sekurak definiuje IDS jako sprzętowe lub programowe rozwiązania służące do wykrywania prób ataków na infrastrukturę sieciową ^[2]. Najważniejsza cecha odróżnia go od systemu IPS: IDS rozpoznaje zagrożenie, ale nie przerywa przepływu ruchu ^[3]. NIST opisuje obie klasy łącznie jako systemy wykrywania i zapobiegania włamaniom (IDPS) w publikacji SP 800-94 z lutego 2007 roku ^[1].

Jak działa

IDS zbiera dane z czujników, porównuje je z regułami albo z modelem normalnego zachowania i zapisuje zdarzenie, gdy znajdzie niezgodność. Alert trafia do administratora, do systemu SIEM (Security Information and Event Management) albo do zespołu SOC (Security Operations Center), który decyduje o reakcji. Schemat poniżej pokazuje ten obieg.

RYS. 1Obieg zdarzenia w IDS

Stosuje się dwie metody wykrywania; szerzej opisuje je hasło wykrywanie sygnaturowe i heurystyczne. Metoda sygnaturowa porównuje komunikację z regułami opisującymi znane ataki ^[2]. Jest skuteczna wobec znanych technik, ale słabo radzi sobie z nowymi ^[3]. Metoda anomalii buduje model zaufanego zachowania i zgłasza odchylenia od normy; lepiej wykrywa nowe zagrożenia, ale daje więcej fałszywych alarmów ^[3].

Sieciowy IDS często działa na kopii ruchu, a nie w jego torze. Dlatego jego awaria nie przerywa działania usług, ale też nic nie zatrzymuje. Do analizy treści ruchu używa DPI (deep packet inspection).

Rodzaje

NIST dzieli technologie IDPS na cztery klasy ^[1]. Sekurak używa podobnego podziału i wymienia typowe narzędzia ^[2].

Suricata, utrzymywana przez fundację OISF, określa się jako wydajny silnik sieciowego IDS, IPS i monitorowania bezpieczeństwa sieci ^[5]. Wiele narzędzi może więc pracować w obu trybach, a o różnicy decyduje sposób wdrożenia.

Sekurak wymienia jeszcze trzecią, pośrednią kategorię: NNIDS, czyli systemy łączące cechy rozwiązań sieciowych i hostowych ^[2]. Wybór rodzaju zależy od tego, co trzeba zobaczyć. Czujnik sieciowy obejmuje wiele maszyn naraz, ale widzi tylko ruch, który przez niego przechodzi. Czujnik hostowy widzi pliki, procesy i logi jednego serwera, więc zauważa także działania, które nie zostawiają śladu w sieci, na przykład zmianę pliku przez już uruchomiony skrypt. W małych instalacjach, takich jak pojedynczy serwer WWW, zwykle wystarcza IDS hostowy uzupełniony o analizę logów serwera. W większych sieciach oba rodzaje działają razem, a ich alerty zbiera jeden system.

W WordPressie

Na stronie WordPress najbardziej przydaje się IDS hostowy. Sekurak opisuje trzy główne zadania HIDS: analizę plików dziennika z filtrowaniem krytycznych wpisów, kontrolę integralności plików oraz wykrywanie rootkitów ^[4]. Narzędzia do kontroli integralności przygotowują listy krytycznych plików z datami modyfikacji, rozmiarami, numerami i-węzłów i uprawnieniami ^[4].

To odpowiada typowym śladom włamania na WordPressa:

• Nowy albo zmieniony plik PHP. MITRE ATT&CK zaleca przy wykrywaniu webshelli obserwować tworzenie nieoczekiwanych skryptów, m.in. plików .php, w katalogach serwera WWW ^[7]. W WordPressie takim miejscem bywa katalog wp-content/uploads.
• Nietypowe procesy. ATT&CK wskazuje też procesy serwera WWW uruchamiające powłokę albo interpretery skryptów ^[7].
• Zmiany w rdzeniu. Monitorowanie integralności plików porównuje pliki z wzorcem. W Wazuh moduł FIM zapisuje sumę kryptograficzną i atrybuty plików, a przy zmianie porównuje je z tym wzorcem i zgłasza utworzenie, modyfikację lub usunięcie ^[6].
• Wzorce w logach. Seria nieudanych logowań w wp-login.php to sygnał ataku siłowego; narzędzia takie jak fail2ban łączą wykrycie w logach z blokadą adresu, więc działają już jak IPS.

Wtyczki bezpieczeństwa, które zapisują zdarzenia w panelu i wysyłają powiadomienia, pełnią część funkcji HIDS, ale działają wewnątrz tej samej aplikacji, którą chronią. Po przejęciu strony napastnik może je wyłączyć, dlatego kontrolę integralności warto prowadzić także spoza WordPressa.

Zagrożenia i ograniczenia

• Brak reakcji. IDS tylko alarmuje ^[3]. Jeśli nikt nie czyta alertów, wykrycie nie ma skutku.
• Fałszywe alarmy. Kapitan Hack wskazuje dużą liczbę alarmów false positive jako istotne ograniczenie, które wymaga ludzi do obsługi incydentów ^[3]. Nadmiar alertów prowadzi do zmęczenia alertami.
• Ruch szyfrowany. Sieciowy IDS nie widzi treści ruchu TLS bez odszyfrowania, więc na serwerach WWW ważniejszy bywa czujnik hostowy.
• Nieznane techniki. Sygnatury nie wykryją ataku, którego nie opisują ^[3].

Dobre praktyki

1. Alerty kieruje się do miejsca, które ktoś regularnie przegląda, na przykład do SIEM (Security Information and Event Management) albo na adres dyżurny.
2. Reguły stroi się na podstawie rzeczywistego ruchu, żeby ograniczyć fałszywe alarmy.
3. Wzorzec integralności plików tworzy się na czystej instalacji i odświeża po każdej aktualizacji rdzenia i wtyczek.
4. IDS łączy się z innymi warstwami: WAF blokuje znane ataki na aplikację, a IDS zgłasza to, co przeszło.
5. Logi IDS przechowuje się poza monitorowanym serwerem, żeby napastnik nie mógł ich usunąć.