Obrona przed atakami – IDS cz. 2
1 Ataki i alarmy
Systemy wykrywania intruzów nie informuj , czy zauwa ony atak był skuteczny. W
poł czeniu z du liczb fałszywych alarmów mo e przerodzi si to w administracyjny
koszmar, a nawet - co bardziej prawdopodobne - w ignorowanie systemu NIDS. Taki stan
rzeczy stwarza dogodne warunki do przeprowadzenia ataku DoS na sam system NIDS oraz
jego operatorów. Atak taki implementuj m.in. narz dzia Stick oraz Snot. Sposób
post powania obu programów jest podobny: posiadaj c baz sygnatur ataków systemu Snort,
generuj one pakiety, których wykrycie przez system NIDS uruchamia alarm. Skutkiem
takiego działania mo e by :
zaj cie wszystkich zasobów sensora systemu NIDS, co uniemo liwia jego prawidłowe
działanie,
zapełnienie przestrzeni dyskowej przeznaczonej na logi systemu. Informacje o
dalszych atakach nie b d pami tane, a zapełnienie dysku mo e spowodowa przerw
w działaniu systemu NIDS,
wygenerowanie liczby alarmów, która przekracza fizyczne mo liwo ci sprawdzenia
ich przez administratora.
Generator pakietów losowo wybiera sygnatur z bazy, co utrudnia jego wykrycie
poprzez szukanie stałych sekwencji ataków. Preferowane s sygnatury korzystaj ce z
protokołów bezpoł czeniowych, np. ICMP, UDP, poniewa niektóre systemy NIDS
sprawdzaj kontekst ataku poprzez budowanie tablicy stanów poł cze . Stworzenie na
podstawie sygnatury i wysłanie segmentu TCP bez wcze niejszego nawi zania poł czenia
spowoduje odrzucenie danego pakietu przez system NIDS. Pakiet taki mógłby równie zosta
odrzucony przez ledz c stany poł cze zapor ogniow lub router. Mo na stworzy
program, który byłby w stanie nawi zywa pełne poł czenie TCP, ale wtedy atakuj cy
musiałby zdradzi swój adres IP. Korzystaj c z protokołów bezpoł czeniowych, mo na adres
nadawcy sfałszowa . Według raportu Network Security Services, Snort, RealSecure oraz
Cisco Secure IDS s podatne na atak przy u yciu narz dzi Snot oraz Stick. Nie powoduje on
zaprzestania działania systemów NIDS, a jedynie generuje fałszywe alarmy.
Ataki DoS s skuteczne, bowiem producenci systemów NIDS minimalizuj liczb
fałszywych alarmów, ale przy zało eniu pracy w rodowisku o normalnej charakterystyce
ruchu sieciowego.
Sytuacja, w której pakiety uruchamiaj ce alarm generowane s umy lnie, zwykle nie
jest brana pod uwag . Stick jest w stanie wygenerowa 450 alarmów w ci gu dwóch sekund.
Aby atak taki był skuteczny, atakuj cy nie potrzebuje ł cza o du ej przepustowo ci. Szanse,
e administrator nawet przy kilkudziesi ciu alarmach na sekund sprawdzi je wszystkie, s
znikome.
System NIDS raportuje o wykryciu zdarzenia, nie informuje jednak, czy atak zako czył
si sukcesem. Cz
sieciowych systemów IDS rozpoznaje rodzaj systemu operacyjnego
chronionej maszyny i nie raportuje o próbach ataków, które go nie dotycz . Nie jest to
rozwi zanie idealne, bowiem administrator powinien wiedzie o zaistnieniu ataku, niezale nie
od jego skutku. Stara si temu zaradzi program ClearResponse firmy Psionic, znanej z
programów PortSentry, HostSentry oraz LogSentry. Według producenta, ClearResponse
współpracuje z systemami NIDS i dostarcza automatycznie odpowiedzi, czy alarm jest
fałszywy. Program jest w stanie odfiltrowa nieudane ataki, zwracaj c uwag administratora
na udane wtargni cia. System NIDS nadal b dzie raportował o nieudanych atakach, lecz
wył cznie informacyjnie.
Zautomatyzowanie procesu sprawdzania alarmów pozwala na analiz ka dego
zdarzenia. ClearResponse nie wymaga instalacji agentów na zdalnych maszynach. Zamiast
tego polega na istniej cym systemie uwierzytelniania.
Po zgłoszeniu zdarzenia przez system NIDS ClearResponse zaczyna kilkufazow
analiz :
1.
Okre la rodzaj systemu operacyjnego b d cego celem ataku. Informacja ta
potrzebna jest do ustalenia, czy docelowe urz dzenie jest podatne na dany atak.
2.
Je li system jest podatny na atak, nast puje sprawdzenie, czy łaty chroni ce przed
danym atakiem zostały zainstalowane.
3.
Je li system jest podatny na atak, ClearResponse zaczyna szczegółowe badanie
systemu, które obejmuje:
analiz rejestru, systemu oraz logów,
przeszukanie okre lonych lokalizacji w poszukiwaniu ladów ataku,
inne czynno ci maj ce na celu potwierdzenie sukcesu lub pora ki ataku.
4.
W razie stwierdzenia włamania ClearResponse zbiera dowody i umieszcza je w
bezpiecznym miejscu.
5.
Do administratora wysyłana jest informacja o wykryciu włamania i przyj tej
drodze post powania oraz kopia zebranych dowodów.
ClearResponse nie zast pi jednak profesjonalistów od bezpiecze stwa sieciowego.
Zawsze nale y powiadomi administratora, który powinien umie zinterpretowa
przedstawione dowody włamania i zdecydowa o dalszym post powaniu. Dost pna wersja
ClearResponse potrafi współpracowa jedynie z systemami RealSecure oraz Cisco Secure
IDS.
2 IDS a szyfrowanie
Sieciowe systemy IDS badaj zawarto przechwyconych pakietów. Je li jednak
pakiety te s zaszyfrowane, system traci mo liwo ci zbadania danych przez nie
przenoszonych. Wiele ataków wykorzystuje to w celu unikni cia wykrycia. Problem dotyczy
m.in. popularnych protokołów SSL oraz IPSec. SSL jest wykorzystywany do zabezpieczania
transakcji w Internecie, np. w sklepach online. Zapewnienie poufno ci jest w takich
przypadkach jak najbardziej po dane. Niestety, zaszyfrowany mo e by równie atak na
serwer WWW, czego system NIDS nie jest w stanie zidentyfikowa .
Protokół IPSec jest powszechnie wykorzystywany w wirtualnych sieciach prywatnych.
Mo e działa w trybie transportowym i tunelowym. Pierwszy szyfruje jedynie zawarto ,
pozostawiaj c widoczne nagłówki pakietu; wykorzystywany jest w transmisji punkt-punkt.
Podejrzenie zawarto ci pakietów bez znajomo ci klucza wymagałoby złamania zabezpiecze
protokołu IPSec. W trybie tunelowym szyfrowana jest zawarto pola danych pakietu wraz z
nagłówkami. Do tak zaszyfrowanego pakietu dodawany jest nowy nagłówek IP z adresem
drugiego ko ca tunelu. W trybie tym mog pracowa dwa hosty komunikuj ce si
bezpo rednio, jest on jednak wykorzystywany głównie w bramach IPSec.
Brama to specjalne urz dzenie umieszczane zwykle na styku sieci LAN/WAN, które
szyfruje ruch wychodz cy z sieci LAN. Wykorzystywane jest ono do bezpiecznego ł czenia
dwóch sieci LAN za pomoc sieci rozległej. W sieciach LAN ruch nie jest szyfrowany.
Brama IPSec szyfruje jednak poł czenia pomi dzy sieciami LAN. Jest to proces
niezauwa alny dla u ytkowników. W trybie tunelowym niezb dne jest odpowiednie
zlokalizowanie systemu NIDS, tak by widział on pakiety, zanim zostan one zaszyfrowane
lub dopiero po ich rozszyfrowaniu. Sprowadza si to do umieszczenia sensorów systemu
NIDS za bram IPSec po stronie sieci lokalnej.
Problem ten nie dotyczy niektórych systemów NNIDS oraz HIDS, np. Entercept, Okena
Stormwatch, RealSecure Server Sensor. Programy te, korzystaj c z bezpo redniego dost pu
do chronionej maszyny, badaj zawarto pakietów ju po ich rozszyfrowaniu przez system
operacyjny.
3 Intrusion Detection and Response
Współczesne mechanizmy obronne systemów komputerowych coraz bardziej - zarówno
w terminologii, jak i taktyce - upodabniaj si do działa stricte militarnych. Przechodz te
podobn ewolucj - od statycznych, okopanych fosami i " cianami ogniowymi" fortec do w
pełni dynamicznej walki manewrowych i technologicznie zaawansowanych sił.
Technika, o której mowa, okre lana jako Intrusion Detection and Response (active
response), w działaniu przypomina urz dzenia walki radioelektronicznej - identyfikuje rodki
napadu przeciwnika i zakłóca ich działanie, zmniejszaj c w ten sposób ich skuteczno .
Niestety tylko "zmniejsza", poniewa i w tej dziedzinie trwa wy cig mi dzy atakuj cym i
broni cym.
Mechanizm aktywnej reakcji (active response) wymaga wykrycia symptomów i
parametrów ataku. Jest to niezb dne, by wiedzie , kiedy i komu odpowiedzie . Zatem
komponentem czynnej obrony b dzie system IDS. Mo e on tylko dostarcza informacji o
ataku - poprzez zapis do logów lub przekazanie komunikatu innym aplikacjom - lub reagowa
samodzielnie, je li ma zaimplementowane odpowiednie procedury, np. w formie wtyczek
(plug-ins). Od strony technicznej czynna obrona mo e polega albo na przerwaniu danej sesji
TCP (session sniping), albo na dopasowaniu konfiguracji ciany ogniowej (firewall update) i
zazwyczaj okresowym (rzadko permanentnym) zablokowaniu dost pu intruzowi w cało ci lub
tylko do wybranego portu. "Przeci cie" sesji odbywa si na ogół poprzez zmylenie stosu IP co
do stanu sesji lub poł czenia, np. poprzez wysłanie pakietu TCP z flag RST (reset) do obu
stron sesji dla jej zako czenia lub komunikatu ICMP do nadawcy, np.
ICMP_NET_UNREACH, ICMP_HOST_UNREACH lub ICMP_PORT_UNREACH.
Zastosowanie mechanizmu czynnej obrony ma sens tylko wtedy, gdy zostanie wykryty
prawdziwy atak. Mo e zdarzy si sytuacja, w której symptom ataku pojawi si w normalnej
komunikacji i zostanie ona przerwana, tzw. false-positive. Aktywna obrona mo e równie
odwróci si przeciwko broni cemu, je li intruz odkryje lub zało y funkcjonowanie tej
techniki w systemie IT, który jest celem ataku. Mo e on spowodowa szereg fałszywych
alarmów pozornie pochodz cych od współdziałaj cych komputerów - zablokowanie im
komunikacji sparali uje system IT i b dzie faktycznie form ataku DoS.
Zastrze enie to dotyczy przede wszystkim techniki uaktualnienia reguł cian
ogniowych, podobnie jak sytuacja, kiedy intruz atakuje z adresu IP przydzielanego
dynamicznie i dzi ki temu blokuje go w danej lokalizacji na dłu szy czas innym
u ytkownikom. Łatwo sfingowania ródła pakietu dotyczy zwłaszcza protokołów ICMP i
UDP. Dlatego u ywanie mechanizmów active response nie powinno by uzale nione od
działa podejmowanych za pomoc tych protokołów - do wykorzystania pozostaje protokół
transportowy TCP.
Aby obrona była skuteczna, czas reakcji na atak musi zosta zminimalizowany, eby nie
pozostawi intruzowi czasu na wyrz dzenie szkód. O powodzeniu lub niepowodzeniu ataku i
przeciwdziałania mog zadecydowa milisekundy. Nie jest to wcale przesada. Niektórym
zautomatyzowanym technikom penetracji systemów komputerowych rzeczywi cie wystarcz
ułamki sekundy do wyrz dzenia szkód lub otwarcia nieautoryzowanego dost pu z zewn trz.
Istniej równie techniki pozwalaj ce skutecznie obej mechanizm active response.
Atakuj cy dysponuje przewag w postaci wykonania pierwszego ruchu, nim atak zostanie
zauwa ony i zaklasyfikowany. Podzielenie kodu exploitu mi dzy kilka pakietów sprawia, e
obserwuj cy komunikacj system IDS musi najpierw zło y pakiety z danej konwersacji w
strumie - dopiero wtedy jest w stanie dopasowa wzorzec z bazy sygnatur do
zgromadzonych danych. W tym czasie pakiety z exploitem znajduj si ju w buforze
wej ciowym TCP zaatakowanego komputera. Je li u yty w ataku exploit wymaga interakcji,
skuteczne mo e by nawet postawienie zapory przy u yciu firewalla, pod warunkiem e
odb dzie si to przed dalszym ci giem konwersacji.
Je li exploit nie wymaga dalszej komunikacji mi dzy atakuj cym i ofiar , to czas
reakcji wyznacza chwila, w której kod exploitu przesłany zostanie z bufora TCP do
zaatakowanej aplikacji. Jest to czas na u ycie session sniping - przesłanie odpowiednio
wcze nie pakietu z flag RST spowoduje wyrzucenie z bufora zło liwych pakietów, nim dotr
do wła ciwego celu. Blokowanie ruchu w inny sposób nie pomo e. Metodzie tej daleko
jednak do stuprocentowej skuteczno ci.
Atakuj cy mo e ustawi inkryminowanym pakietom flag PUSH, wymuszaj c
dostarczenie pakietów do aplikacji bez buforowania - tak szybko, jak to mo liwe. Mo e to
wystarczy do wykonania operacji zwi zanej z exploitem, np. zostawienia "tylnego wej cia"
w zaatakowanym systemie komputerowym. Dalszy atak mo e odbywa si wtedy poza
zakresem detekcji systemu IDS. Obej cie takie b dzie skuteczne tak e przy dynamicznym
zarz dzaniu firewallem; co prawda zablokowany zostanie dost p z adresu, z którego u yto
zdalnego exploitu, jednak dalsza penetracja systemu mo e odbywa si - dzi ki
zainstalowanym backdoors - z innych lokalizacji.
Inn mo liwo ci omini cia obrony przez session sniping jest przesłanie wi kszej liczby pakietów w
porcji, ni spodziewa si IDS wysyłaj cy TCP RST. Warunkiem skuteczno ci przerwania konwersacji przez
pakiet TCP RST jest otrzymanie przeze odpowiedniego numeru sekwencji. Je li atakuj cy po trzech pakietach
zawieraj cych exploit prze le czwarty, nieszkodliwy pakiet - wysłany przez IDS pakiet TCP RST wypadnie z
sekwencji i przez wi kszo stosów IP zostanie zignorowany. Sesja b dzie trwała i to bez mo liwo ci
zweryfikowania skuteczno ci session sniping. Metoda ta jest skuteczna zwłaszcza przy u yciu exploitów
wymagaj cych dalszego utrzymania sesji.
4 Integracja IDS z firewall
Niektóre koncepcje wdra ania systemów IDS zakładaj , e system IDS po wykryciu
ataku powinien mie mo liwo rekonfiguracji systemu zaporowego. Koncepcja ta posiada
jednak wi kszy wymiar marketingowy jak praktyczny. Na pierwszy rzut oka pomysł ten
wydaje si interesuj cy, jednak wnikliwa analiza skutków zastosowania go w praktyce
prowadzi do przeciwnych wniosków. Automatyczne blokowanie na Firewall adresów, z
których wywodzi si atak wydaje si nierozs dne z kilku powodów. Po pierwsze,
włamywacze posługuj si zazwyczaj komputerami/sieciami osób i firm trzecich. W trakcie
prowadzenia wielu ataków mog tak e wykorzystywa dowolne, przypisane sobie adresy IP.
Łatwo wyobrazi sobie sytuacj , w której włamywacz wiedz c, lub nawet tylko
podejrzewaj c, e firma stosuje tak strategi obrony wykorzysta do ataku sieci (lub tylko ich
adresy) nale ce do jej kluczowych partnerów lub klientów. W ci gu kilku minut firma mo e
wi c sama pozbawi si kontaktu ze wiatem. Po drugie, wzi wszy pod uwag stosunkowo
du o fałszywych alarmów generowanych przez systemy IDS, taka automatyzacja mo e
oznacza w praktyce dla administratorów wi cej, a nie mniej pracy.
Inna koncepcja integracji IDS z Firewall, znajduj ca wi ksze zastosowanie praktyczne
polega na utrzymywaniu wspólnej bazy rejestrowanych przez nie zdarze . System IDS
przesyła w czasie rzeczywistym logi do stacji zarz dzaj cej Firewall, aby tam mogły zosta
poddane wspólnej analizie. Takie podej cie stwarza lepsze mo liwo ci wykrywania nadu y
bezpiecze stwa i wyja niania zaistniałych incydentów. Przykładem mo e by opracowany
przez Check Point protokół ELA (Event Logging API), poprzez który zdarzenia z IDS mog
w czasie rzeczywistym by przesyłane do konsoli zarz dzania Firewall (SmartCenter) i tam
poddawane korelacji i analizom.
5 IDS in-line
Tym, którzy wybieraj si na internetow wojn z u yciem Intrusion Detection and
Response nale y si ostrze enie: nie jest to technologia absolutnie skuteczna. Techniki jej
neutralizacji s znane. Zastosowana w odpowiednich warunkach i w zestawieniu cho by ze
starannym zakładaniem "łat" na znane luki w systemach operacyjnych i aplikacjach pomo e
na pewno odeprze mniej profesjonalnie przeprowadzone ataki, a pozostawi czas i siły do
namysłu przed odparciem tych najgro niejszych.
U ycie opisanych do tej pory systemów IDS współpracuj cych z firewallem z biegiem
czasu przestało by wystarczaj ce. Obecnie konieczne jest zastosowanie zintegrowanego
systemu zabezpiecze , który wykrywa ataki i blokuje je w czasie rzeczywistym. Na rynku
pojawiła si zatem nowa generacja zabezpiecze okre lana jako in-line IDS lub Deep Packet
Inspection. Rozwi zania te s co do zasady działania podobne do systemów firewall. Ruch
wchodzi do urz dzenia IDS przez interfejs sieciowy i wewn trz jest poddawany analizie, a
nast pnie wychodzi z urz dzenia drugim interfejsem. Dzi ki temu kontrola ruchu
sieciowego jest łatwiejsza, pojawia si mniej jak w zwykłych IDS fałszywych alarmów i
co najwa niejsze całkowicie eliminowane jest zagro enie, e IDS „zgubi pakiety”. Istotne
jest tak e, e w in-line IDS ataki mog by w czasie rzeczywistym skutecznie blokowane.
Zwykły system IDS, nasłuchuj c sie identyfikuje zdarzenia w czasie gdy intruzi wykonali
ju ataki na chronione zasoby i w praktyce nie jest w stanie ich zablokowa . Systemy IDS
działaj ce w trybie in-line to m.in. Check Point SmartDefence, ISS RealSecure Guard i
OneSecure (obecnie NetScreen IDP).
Realna wydajno rozwi za in-line IDS wynosi od 100 do 400 Mb/s, co oznacza, e
na razie mo na je stosowa do ochrony segmentów sieci Fast Ethernet oraz mało
obci onych sieci Gigabitowych.
Poni ej przedstawione zostało porównanie własno ci systemów IDS zintegrowanych z
firewallem i systemów in-line IDS.
System IDS zintegrowany z In-line IDS
firewallem
Ochrona zasobów systemu
Brak mo liwo ci blokowania
Atak jest blokowany przed
informatycznego przed atakami
ataków i ochrony zasobów systemu uzyskaniem dost pu do chronionych
informatycznego. Reakcja Sniffer-
zasobów systemu informatycznego.
IDS odbywa si po wykonaniu
In-line IDS blokuje pakiety, które
ataku. Typowy atak sieciowy to
wykonuj atak. In-line IDS w razie
uruchomienie exploit typu
potrzeb realizuje tak e funkcje
przepełnienie bufora, załadowanie
firewall.
shellcode i instalacja backdoor.
Czas trwania ataku jest bardzo
krótki, a Sniffer-IDS nie ma
mo liwo ci jego zablokowania
poprzez wykonanie TCP Reset.
Zablokowanie na firewall adresu IP,
z którego wykonano atak tak e jest
nieskuteczne. Intruz mo e bowiem
maj c zainstalowany backdoor
uzyska dost p do systemu
u ywaj c innego adresu IP.
Wykrywalno ataków
Analiza ruchu sieciowego na
In-line IDS analizuje cało ruchu
zasadzie nasłuchu jest
sieciowego przepływaj cego przez
skomplikowana i istnieje zagro enie urz dzenie zabezpiecze . Poprawne
„gubienia” pakietów. Sniffer-IDS
identyfikowanie ataków jest
ma utrudnione zadanie z uwagi na
łatwiejsze jak w Sniffer-IDS (m.in.
wyst puj ce w sieci przeci enia,
w in-line nie ma zagro enia
retransmisje TCP, fragmentacj
„zgubienia” pakietów, in-line IDS
oraz ró n kolejno napływaj cych mo e wykonywa kompletowanie
fragmentów datagramów. Na skutek poddanych fragmentacji
tego zabezpieczenia Sniffer-IDS
datagramów IP przed
charakteryzuj si du liczb
wpuszczeniem ich do sieci
fałszywych alarmów (ang. false
chronionej).
positives) i nie wykrywaj
wszystkich ataków, nawet je eli
posiadaj w bazie ich sygnatury.
Zagro enie zakłócania pracy
Blokowanie na firewall adresów IP, In-line IDS blokuje tylko pakiety
systemu informatycznego
z którego zostały zidentyfikowane
wykonuj ce atak. Zagro enie
ataki jest bardzo niebezpieczne (np. wprowadzania zakłóce w pracy
intruzi stosuj c IP Spoofing mog
systemu informatycznego jest
wykonywa ataki u ywaj c adresów niewielkie.
IP nale cych do oddziałów firmy,
b d jej klientów i partnerów).
O jako ci systemów wykrywania intruzów decyduje wiele własno ci. Do najbardziej
istotnych z nich mo na zaliczy :
Wykrywalno ataków - system IDS identyfikuje ataki, dla których posiada
zdefiniowane sygnatury i jest odporny na techniki oszukiwania zabezpiecze (tzw.
evasion techniques).
Liczba fałszywych alarmów - system IDS dokładnie analizuje ruch sieciowy i
generuje niewielk liczb fałszywych alarmów (tzw. false positives).
Wydajno - system IDS nawet w warunkach du ego obci enia sieci poddaje analizie
cało ruchu sieciowego tzn. nie gubi pakietów.
Baza sygnatur i jej aktualizacja - system IDS posiada informacje na temat du ej
liczby ataków i dane te s cz sto aktualizowane,
Zakres reakcji - system IDS w razie wykrycia ataku podejmuje stosowne działanie
(np. powiadamia administratora, zamyka sesj TCP).
Dostrajanie zabezpiecze - polityka bezpiecze stwa IDS jest dostosowana do potrzeb i
specyfiki chronionych systemów (m.in. administrator decyduje jaki ruch podlega
kontroli oraz mo e definiowa własne sygnatury zdarze i metody ich obsługi).
Zarz dzanie zabezpiecze - administrator IDS ma do dyspozycji dedykowane
narz dzia do monitorowania sieci, analizy zdarze i wykrywania nadu y
bezpiecze stwa oraz sprawnego zarz dzania systemu (m.in. scentralizowanej
instalacji polityki bezpiecze stwa i aktualizacji baz sygnatur na odległych sensorach
IDS).
6 IDS to nie wszystko
Zainstalowanie systemu IDS nie jest wcale równoznaczne z zapewnieniem
bezpiecze stwa. Nie ma systemów IDS w pełni zautomatyzowanych, które nie wymagaj do
działania adnego nadzoru ze strony wykwalifikowanej obsługi. Wspomniane tu strojenie
systemu NIDS to zaledwie czubek góry lodowej. Aktualizacja, przegl danie logów,
reagowanie na alarmy - wszystkie te obszary pomimo rosn cej automatyzacji musz by pod
opiek człowieka. Fałszywe poczucie bezpiecze stwa jest niejednokrotnie gro niejsze w
skutkach od nieposiadania jakichkolwiek zabezpiecze . Najlepiej samemu przekona si o
skuteczno ci posiadanego systemu wykrywania intruzów. Testy pozwalaj zapozna si z
posiadanym systemem NIDS, rodzajami alarmów przez niego zgłaszanych oraz
okoliczno ciami ich powstawania. W ród wielu programów napisanych specjalnie w tym celu
s zarówno programy darmowe (np. Firewall Tester), jak i komercyjne (np. HailStrom, IDS
Informer).
Firewall Tester symuluje poł czenia TCP pozwalaj ce testowa systemy dokonuj ce analizy kontekstowej
ruchu sieciowego. Implementuje techniki unikania wykrycia oraz obsługuje fragmentacj IP oraz TCP. Potrafi
korzysta z bazy reguł Snorta do tworzenia pakietów testowych.
HailStorm nale y do programów testuj cych zabezpieczenia sieci. Do przeprowadzania symulowanych ataków
wykorzystuje wewn trzn baz wzorców; umo liwia te definiowanie własnych wzorców. Pozwala testowa
protokoły warstw: sieciowej, transportowej i aplikacji oraz sprawdza skuteczno zapór ogniowych i systemów
IDS. Wykorzystuje techniki unikania wykrycia, daj c administratorowi kontrol nad ró nymi ich rodzajami.
IDS Informer został stworzony z my l o testowaniu systemów IDS. Dost pne s dwie wersje programu:
Standard oraz Professional. Wg producenta - Blade Software - IDS Informer przeprowadza prawdziwe,
aczkolwiek nieszkodliwe ataki na wybrane systemy. Technologia ta otrzymała nazw S.A.F.E. (Simulated
Attacks For Evaluation). Zalet programu s regularne aktualizacje bazy danych o atakach, dzi ki czemu mo na
na bie co bada skuteczno systemu IDS. Daje to pewno , e system IDS jest skonfigurowany poprawnie i
działa zgodnie z oczekiwaniami.
Niezale nie od dost pno ci programów testuj cych istnieje przekonanie, e nie ma
lepszego sposobu na sprawdzenie skuteczno ci systemu IDS ni przeprowadzenie ataków
samemu. Daje to stuprocentow pewno , e system IDS wykrywa i poprawnie identyfikuje
dokładnie taki atak, przed którym serwery i sie maj by chronione.
Producenci systemów IDS staraj si nad a za post pem w technologii sieciowej oraz
nowymi metodami unikania wykrycia. Systemy IDS s ju pod wieloma wzgl dami
skuteczne, ale wci wymagaj dopracowania. Liczba oraz jako dost pnych rozwi za
pozwalaj jednak bez obaw patrze w przyszło technologii wykrywania intruzów.