Ochroniarz w roli komandosa

Rzeczywisty postęp w dziedzinie systemów IDS/IPS dokonuje się powoli. Nowe wersje rozwiązań oferują większą wygodę administratorom, ale niekoniecznie wyższy poziom bezpieczeństwa.

Rzeczywisty postęp w dziedzinie systemów IDS/IPS dokonuje się powoli. Nowe wersje rozwiązań oferują większą wygodę administratorom, ale niekoniecznie wyższy poziom bezpieczeństwa.

Systemy wykrywania włamań mają długą historię, ale ponieważ ich sensowne wdrożenie wymagało bardzo dobrego przygotowania teoretycznego i sporej wiedzy fachowej opartej na praktyce, były to do niedawna rozwiązania elitarne - jeśli mówimy o wdrożeniach "na poważnie". Zagrożenia wciąż jednak rosną, zarówno w ujęciu ilościowym, jak i pod względem wysublimowania, dlatego systemy tego rodzaju cieszą się zainteresowaniem.

Chcąc oferować produkty, dostawcy musieli pogodzić elastyczność konfiguracji z możliwościami zrozumienia przez klientów problematyki ochrony, budżetami, z czasem na szkolenia itd. Tak systemy wykrywania włamań (IDS - Intrusion Detection Systems) przerodziły się w systemy zapobiegania włamaniom (IPS - Intrusion Prevention Systems). Niestety, nie możemy się w związku z tym czuć ani trochę bardziej bezpiecznie.

Potencjalne zagrożenie

Największy wzrost zainteresowania i nadziei na wieksze bezpieczeństwo infrastruktury IT wiąże się obecnie właśnie z systemami HIDS (Host-based IDS - systemy IDS instalowane na urządzeniach - serwerach, komputerach). W dużej mierze dlatego, że możliwości ochrony na poziomie sieci są obecnie uważane za dosyć słabe, jak również z tego powodu, że coraz więcej ataków dotyczy funkcji, interfejsów i protokołów aplikacyjnych oraz funkcji odwołujących się do jądra systemu operacyjnego. Systemy HIDS, czy to IDS czy IDS/IPS, mimo że rzeczywiście bywają skuteczne, nie stanowią magicznego antidotum na wszelkie zło czyhające na poufne dane - można je oszukać i zmylić.

Systemy HIDS realizowane są zazwyczaj w formie modułu jądra systemu operacyjnego lub jako oddzielne urządzenia analizujące odwołania aplikacji i usług sieciowych lub użytkowników do jądra systemu. W tym drugim scenariuszu rozwiązanie HIDS musi mieć dostęp nie tylko do samego jądra chronionego systemu, ale również do całej treści komunikacji systemu ze światem zewnętrznym - dodajmy, w sposób całkowicie przezroczysty. Warunki te są trudne do spełnienia w praktyce, a przy tym poprawne skonfigurowanie systemu HIDS wcale nie jest proste.

Złe zaplanowanie nasłuchu zdarzeń w systemie może prowadzić do jego niestabilności lub spadku wydajności, zaś błędy w konfiguracji nasłuchu sieci mogą skutkować problemami z dostępem do sieci lub działaniem aplikacji (np. automatycznie aktualizowane czarne listy), a nawet do naruszenia prawa, (np. przez zapisywanie skanowanego ruchu na dysku). Tak więc poprzeczka trudności znów została podniesiona.

Automat nie w tym miejscu

Na pewno zwiększyła się wygoda użycia systemów IDS/IPS. Reprezentujące dobre praktyki wstępnie skonfigurowane reguły i wzorce reguł do samodzielnej modyfikacji pozwoliły na zmniejszenie liczby fałszywych alarmów, które stały się przyczyną odrzucenia pierwszej fali systemów IDS przez klientów korporacyjnych.

Mimo to nie można przymykać oczu na fakt, że podstawowe założenia konstrukcyjne systemów IDS/IPS nie zmieniły się od 5-7 lat. Ich zadaniem jest nadal monitorowanie ruchu pod kątem znanych i potencjalnych zagrożeń, blokowanie ich oraz informowanie o tym administratora. Mamy mniej fałszywych alarmów, ale metody "odczytu rzeczywistości" i wnioskowania wciąż są te same.

Tu upatrywałbym problemu, bo cóż z tego, że administrator dowie się, że ruch do aplikacji wzrósł ponad przeciętną wartość, i że w związku z tym co drugi użytkownik został automatycznie odłączony, by nie przeciążyć serwera? Przecież bezpieczeństwo nie polega na "wycinaniu w pień" ruchu, który może okazać się niebezpieczny tylko potencjalnie.

Automatyzacja, która kilka lat temu wydawała się koniecznością, by skłonić firmy do zakupu systemów IDS/IPS, okazała się ślepą uliczką. Problemem systemów IDS/IPS nie jest bowiem automatyzacja reakcji na zagrożenie, lecz niedostatecznie automatyczny i pewny proces oceny tego, na ile zdarzenie jest niebezpieczne. Sygnatury jako rozwiązanie tego problemu wciąż trzymają się mocno, ale w tle widać już nowe podejścia, oparte na analizie kontekstowej zagrożenia (systemy typu TIDS - Target-based IDS, o których pisaliśmy w CW 39/2005).

Niezależnie od tego trendu rozwijane są rozwiązania oparte na modelach interakcji klientów z serwerami i wzorcach prawidłowego funkcjonowania systemów i aplikacji w systemie operacyjnym. Ich filozofia opiera się na filtrowaniu ruchu niespełniającego warunków uznanych za właściwe.

Wygodny albo bezpieczny

Wszystkie te podejścia nie są jeszcze na tyle dojrzałe, aby mówić o stosowaniu ich w wymagających środowiskach. Dlatego w poszukiwaniu dobrego systemu IDS/IPS wciąż nie należy skupiać się na markach czy konkretnych produktach, ale osobach ze stosownym doświadczeniem. Jest to oczywiście niełatwe, być może również kosztowne, ale zakup rozwiązania obiecującego automatyzację zamiast bezpieczeństwa nie wydaje się ani rozsądny, ani tani.

Za rozwojem kompetencji zamiast kupowania rozwiązań przemawia również fakt, że bez względu na możliwości automatyzacji zagrożenia ciągle ewoluują - ich natura zmienia się dosyć szybko. Kto jeśli nie człowiek zoptymalizuje działanie rozwiązania ochronnego pod kątem ataku opracowanego przez innego człowieka?

Jeżeli skuteczność systemów IDS/IPS ma polegać przede wszystkim na ograniczaniu liczby alertów, a nie na rozpoznawaniu i unieszkodliwianiu zaczątków zagrożeń, w ogóle szkoda je wdrażać. Jeśli już koniecznie system IDS/IPS ma być elementem infrastruktury firmowej, najlepiej zacząć od rozwiązań open source, które pozwolą zapewnić w miarę dobrą funkcjonalność bez wydawania sporych kwot na licencje i dodatkowy sprzęt.

Nie będzie to konfiguracja "niezatapialna", ale też nie będzie to duży wydatek skutkujący fałszywym poczuciem bezpieczeństwa. Z biegiem czasu, gdy ludzie zbiorą doświadczenia, łatwiej będzie można sformułować oczekiwania wobec rozwiązania adekwatnego do potrzeb firmy. Łatwiej też będzie rozmawiać z handlowcami oferującymi "unikalne" rozwiązania.

Szkodliwe powiązania

Zjawiskiem często spotykanym w instalacjach systemów IDS/IPS jest sprzężenie takiego systemu z filtrem pakietów (zaporą, firewallem), często na jednym urządzeniu. Skutki takiego sprzężenia mogą być w praktyce (i bywają) odwrotne do zamierzonych. Argumentacja dostawców brzmi mniej więcej tak: sprzężenie IDS/IPS z zaporą pozwala natychmiast odciąć ruch - już przy pierwszej próbie włamania. Problemów związanych z takim myśleniem jest co najmniej kilka.

Po pierwsze, dobrze spreparowany atak DoS odcina firmę od sieci jej własnymi narzędziami. Po drugie, system IDS/IPS nie otrzymuje pełnej informacji o napływającym ruchu (z Internetu, innych podsieci firmowych), gdyż część prób nawiązania połączenia zostanie odciętych na zaporze zanim system IDS/IPS zdąży je przeanalizować. A więc, po trzecie, zapora utrudnia systemowi IDS/IPS wczesne reagowanie, do czego przecież został on stworzony. W większości przypadków owo sprzężenie systemu IDS/IPS z zaporą jest bowiem tylko jednostronne, tzn. system IDS może zmodyfikować konfigurację zapory, a nie na odwrót.

Zawsze byłem zwolennikiem architektury, w której system monitorujący jest całkowicie niezależny od zapory. Jego niezależność jest gwarantem poprawności działania, a jednocześnie utrudnieniem dla potencjalnego włamywacza. Dlaczego więc mielibyśmy płacić za rozwiązania, których logika przeczy zdrowemu rozsądkowi, a ich możliwości analityczne są ograniczone? Producenci IDS nie udowodnili, jak na razie, że ich systemy posiadają możliwości, za które warto płacić.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200