IDS i IPS w architekturze sieci
Zapora kontroluje ruch na granicy stref, lecz jej decyzje opierają się na obserwowanych polach, stanie i regułach. Ruch dopuszczony może zawierać atak aplikacyjny, a zagrożenie może powstać w systemie wewnętrznym. Dlatego analiza obejmuje również komunikację wewnątrz sieci, stan hostów oraz zdarzenia związane z użytkownikami. Wybór punktu pomiaru określa, jakie urządzenia i kierunki będą widoczne, a retencja logów określa, jak długo można sprawdzać alert. Przy projektowaniu warto określić wymagany zakres, koszt przechowywania, ochronę danych osobowych oraz właściciela procesu reagowania. Trzeba także ustalić czas eskalacji i wymagany format audytu. Warto przewidzieć przegląd po wdrożeniu oraz test okresowy. Wynik testu powinien wskazywać zakres ruchu, użyte reguły i zaobserwowany wpływ na usługę.
i systemy zapobiegania włamaniom (IPS) obserwują ruch sieciowy albo zdarzenia hosta. IDS generuje alert, IPS może działać inline i zablokować dopasowany ruch. Oba systemy wymagają źródeł danych, reguł, aktualizacji, obsługi alertów oraz oceny wpływu na dostępność usług. Alert powinien zawierać czas, źródło, cel, regułę, poziom pewności i wykonane działanie, aby można było powtórzyć ocenę. Potok alertów powinien określać deduplikację, mapowanie ważności, powiadomienia i retencję pierwotnej obserwacji.
System wykrywania włamań (IDS)
monitoruje dane i tworzy alerty dotyczące dopasowanych sygnatur, anomalii albo naruszeń polityki. W typowym wdrożeniu IDS działa poza ścieżką ruchu i nie blokuje zdarzenia. Możliwe są również konfiguracje, w których alert uruchamia osobny mechanizm reakcji, dlatego sposób działania trzeba sprawdzić w projekcie systemu.
IDS może otrzymywać kopię ruchu z portu SPAN, portu lustrzanego albo brokera pakietów. Silnik analityczny porównuje dane z regułami, rejestruje wynik i przekazuje alert do systemu obsługi zdarzeń. Alert opisuje obserwację oraz dopasowanie. Administrator ocenia, czy zdarzenie wymaga izolacji hosta, dodatkowych danych lub zmiany reguły. Konfiguracja powinna uwzględniać synchronizację czasu, ochronę logów, obciążenie interfejsu kopiującego oraz obsługę utraconych pakietów.
Wdrożenie out-of-band oddziela awarię lub opóźnienie IDS od głównej ścieżki przekazywania pakietów. IDS nie może jednak zatrzymać ruchu, a port kopiujący może nie przekazać wszystkich ramek przy przeciążeniu, błędnym zakresie VLAN albo braku widoczności szyfrowanego ładunku. Projekt powinien określać, jakie punkty są obserwowane i jak obsługuje się utratę danych. Warto testować widoczność po zmianie topologii oraz porównywać liczbę ramek wejściowych z liczbą ramek analizowanych przez IDS.
Typy IDS według miejsca obserwacji
NIDS obserwuje komunikację w segmencie, a HIDS zbiera zdarzenia z konkretnego hosta. Oba typy mogą uzupełniać się w analizie incydentu, lecz mają inne źródła danych i ograniczenia.
1. Sieciowy system wykrywania włamań (NIDS)
NIDS umieszcza się w punkcie, w którym może otrzymać kopię ruchu danego segmentu. Zakres obejmuje przykładowo komunikację serwerów, stacji roboczych i Internetu, zależnie od topologii, portów kopiujących oraz filtrów. Dokumentacja czujnika powinna wskazywać łącza, VLAN-y, oczekiwane kierunki i metodę sprawdzania kompletności kopii.
NIDS może wskazać wzorzec skanowania, na przykład host z adresem próbujący połączyć się z wieloma serwerami i portami. Taki alert zależy od widoczności ruchu i progów reguły. Sam adres jest punktem obserwowanym, dlatego jego właściciela trzeba ustalić w osobnych logach. Przy NAT analiza powinna uwzględnić port źródłowy i czas, a przy ruchu między przełącznikami także zakres kopiowania.
NIDS zwykle nie widzi treści chronionej przez HTTPS lub inny kanał TLS. Może jednak analizować metadane, parametry handshake, adresy, rozmiary i częstotliwość. Pełna analiza wymaga widoku po odszyfrowaniu albo kontrolowanej inspekcji TLS.
2. Hostowy system wykrywania włamań (HIDS)
HIDS to agent na konkretnym hoście, na przykład serwerze WWW, serwerze bazy danych lub laptopie. Zbiera zdarzenia systemowe, procesy, zmiany plików, logi uwierzytelniania i wybrane dane ruchu przetworzonego przez host. Polityka powinna określać obowiązkowe zdarzenia, ochronę agenta i miejsce przechowywania jego zapisów.
HIDS obserwuje modyfikacje plików wewnątrzhosta, na przykład pliku 'C:\Windows\System32\drivers\etc\hosts', uruchomienie procesu, zmianę rejestru lub zdarzenie uwierzytelnienia. Zakres i wiarygodność alarmu zależą od uprawnień agenta oraz ochrony jego logów.
HIDS może wykryć zmianę pliku albo uruchomienie procesu po podłączeniu zainfekowanego nośnika, nawet gdy NIDS nie otrzymał odpowiedniego ruchu. Agent może również analizować ruch po odszyfrowaniu na hoście. Nie zastępuje to NIDS, ponieważ awaria agenta, jego ominięcie albo brak uprawnień ogranicza obserwację. Wdrożenie wymaga ochrony agenta przed wyłączeniem, sprawdzenia wpływu na wydajność i przesyłania logów do niezależnego magazynu. Dla krytycznych hostów trzeba ustalić, jakie zdarzenia są obowiązkowe i jak potwierdza się działanie agenta.
Metody wykrywania
IDS porównuje obserwacje z wiedzą o znanych zdarzeniach albo z modelem zwykłej aktywności. Obie metody wymagają strojenia, aktualizacji i obsługi alertów.
1. Wykrywanie oparte na sygnaturach
Sygnatura opisuje wzorzec związany ze znanym zagrożeniem, na przykład sekwencję bajtów, polecenie SQL injection albo charakterystyczny przebieg skanowania. Silnik porównuje obserwowany ruch i zdarzenia z biblioteką reguł. Wynik zależy od widoczności, normalizacji protokołu, wersji sygnatur i sposobu aktualizacji. Reguły mogą mieć priorytet, warunki kontekstu i wyjątki, które trzeba testować po zmianie aplikacji.
Dopasowanie sygnatury wskazuje podobieństwo obserwacji do znanego wzorca. Nie rozpoznaje nieopisanych wariantów, nie potwierdza skutku ataku i może wymagać sprawdzenia kontekstu aplikacji.
Zaleta: Dobrze dostrojona reguła szybko wskazuje znane wzorce i może dostarczyć szczegółowego opisu zdarzenia.
Wada: Nowy wariant lub zagrożenie zero-day może nie mieć pasującej sygnatury. Skuteczność zależy od aktualizacji, jakości reguł i wyjątków. Zbyt szerokie dopasowania zwiększają liczbę fałszywych alarmów.
2. Wykrywanie oparte na anomaliach
Model anomalii opisuje typową aktywność według protokołów, relacji serwerów, pory dnia, rozmiaru pakietów i wielkości transferu. Alert powstaje po przekroczeniu progu odchylenia. Model może wymagać okresu uczenia i regularnego dostosowania do zmian w sieci.
Przykładową anomalią może być transfer gigabajtów danych o 3 nad ranem z hosta, który zwykle nie komunikuje się z zewnętrznym serwerem. Wzorzec uzasadnia sprawdzenie harmonogramu kopii, roli hosta i logów aplikacji. Nie jest samodzielnym dowodem ataku, ponieważ legalne zadanie administracyjne może wyglądać podobnie.
Zaleta: Może wskazać nowy wzorzec, którego nie opisuje biblioteka sygnatur, w tym potencjalny atak zero-day.
Wada: Nietypowa, lecz legalna aktywność może wywołać alert. Rzadkie narzędzie diagnostyczne, zmiana harmonogramu albo jednorazowy transfer mogą zwiększyć szum. Zespół musi ustawić progi, wyjątki i proces oceny.
System zapobiegania włamaniom (IPS)
analizuje ruch i może wykonać działanie po dopasowaniu reguły. W odróżnieniu od typowego IDS jest wdrażany inline albo współpracuje z mechanizmem, który może blokować, resetować lub ograniczać komunikację.
W trybie inline pakiety przechodzą przez IPS przed dotarciem do celu. Urządzenie może stosować sygnatury, analizę anomalii i reguły protokołu. Po dopasowaniu może odrzucić pakiet, zablokować przepływ, zresetować sesję lub przekazać alert. Dostępność zależy od przepustowości, konfiguracji wyjątków oraz trybu fail-open albo fail-closed.
Wdrożenie inline wprowadza zależność od urządzenia. Awaria, przeciążenie, błędna sygnatura lub zbyt agresywna reguła mogą zwiększyć opóźnienia, zablokować legalny ruch albo przerwać usługę. Projekt musi określać obejście, monitoring, limity i sposób obsługi awarii. Przed włączeniem blokowania należy sprawdzić tryb obserwacyjny, procedurę wycofania i wpływ na połączenia długotrwałe. Próby powinny obejmować ruch szyfrowany, fragmentację, różne protokoły i obciążenie zbliżone do produkcyjnego.
Działania zapobiegawcze IPS
Po dopasowaniu reguły IPS może wykonać działanie określone przez politykę:
- Odrzucanie pakietów: IPS odrzuca pakiety pasujące do reguły i zapisuje decyzję. Skutek zależy od protokołu oraz miejsca urządzenia w ścieżce.
- Blokowanie ruchu: IPS może dodać czasową regułę dla adresu, portu albo przepływu. Automatyczna blokada wymaga limitu czasu, wyjątków i kontroli, aby ograniczyć skutki błędnego dopasowania.
- Resetowanie połączenia: Dla sesji TCP IPS może wysłać segmenty RST do stron, aby przerwać połączenie. Działanie wymaga widoczności obu kierunków i może być ograniczone przez topologię albo brak widoczności ruchu w punkcie egzekwowania.
- Alarm i logowanie: IPS zapisuje dopasowanie, decyzję i istotne pola ruchu oraz przekazuje alert do dalszej oceny zgodnie z konfiguracją.
Błędy klasyfikacji alertów
IDS i IPS mogą błędnie zaklasyfikować obserwację. W analizie trzeba odróżnić zdarzenia legalne oznaczone jako zagrożenie od ataków pominiętych przez system. Oba błędy wpływają na pracę zespołu i dostępność usług.
Fałszywie dodatni alert (false positive)
Fałszywie dodatni alert powstaje, gdy system oznacza legalną aktywność jako złośliwą.
Duża liczba takich alertów powoduje zmęczenie alarmami i opóźnia ocenę ważnych zdarzeń. W IPS błędna decyzja może zablokować użytkownika, aplikację krytyczną albo połączenie partnera. Strojenie reguł powinno uwzględniać wyjątki, tryb wdrożenia, priorytet usługi i możliwość ręcznego wycofania blokady.
Fałszywie ujemny alert (false negative)
Fałszywie ujemny alert występuje, gdy system nie wykrywa rzeczywistego ataku albo nie przekazuje odpowiedniego alertu.
Przyczyną może być brak widoczności, szyfrowanie, nieaktualna sygnatura, obejście reguły, przeciążenie albo zbyt niski priorytet zdarzenia. Brak alertu nie świadczy o braku aktywności, dlatego analiza powinna uwzględniać dane hosta i źródła niezależne od IDS.
Strojenie IDS/IPS polega na pomiarze obu rodzajów błędów, aktualizacji reguł, weryfikacji wyjątków i sprawdzaniu wpływu blokad na usługi. Czułość, opóźnienie reakcji i dostępność są ustalane według ryzyka oraz roli systemu. Wyniki powinny być oceniane po aktualizacji sygnatur, zmianie topologii i wdrożeniu nowej usługi. Raport z przeglądu powinien wskazywać testowany ruch, zmienione progi, zaobserwowane błędy, właściciela decyzji i termin dalszych działań.
Zintegrowane funkcje bezpieczeństwa
Produkty bezpieczeństwa mogą łączyć filtrowanie, identyfikację aplikacji, IDS, IPS, VPN i ochronę punktów końcowych. Nazwa produktu nie określa dokładnego zakresu funkcji, dlatego trzeba sprawdzić tryb pracy, źródła sygnatur oraz konfigurację.
- Zapora nowej generacji (NGFW): NGFW zwykle łączy filtrowanie stanowe z identyfikacją aplikacji, głęboką inspekcją pakietów i wybranymi funkcjami IPS. Pełna analiza treści zależy od szyfrowania, modułu oraz trybu inline. Działanie sygnatur, blokad i wyjątków wymaga osobnej konfiguracji.
- Ujednolicone zarządzanie zagrożeniami (UTM): UTM może łączyć zaporę, NIDS/NIPS, ochronę antywirusową bramy, filtrowanie treści i VPN w jednym urządzeniu. Zakres funkcji zależy od produktu, licencji i wydajności. Konsolidacja upraszcza zarządzanie, lecz wymaga oceny przepustowości, widoczności oraz skutków awarii.
IDS zapewnia obserwację i alerty, a IPS może wykonać reakcję inline. Skuteczna architektura łączy te funkcje z logami hostów, zarządzaniem incydentami i kontrolą zmian. Ochrona zależy od widoczności, jakości reguł, aktualizacji, strojenia oraz sprawdzenia wpływu na usługi. Należy także określić właściciela alertu, czas reakcji, sposób eskalacji i wymagany zapis audytowy.