gorion's e-security thoughts

Liczba podkreślona na powyższym rysunku nazywana jest "Initial Sequence Number" - ISN. Zawarta jest zawsze w pakiecie SYN, przy pierwszym kroku handshake. Sekwencja ta rozpoczyna się wysłaniem SYN do (192.168.0.1). "mss 1460" odnosi się do maksymalnej wielkości segmentu. Wartość 1460 mierzona jest w bajtach czyli po prostu 1460 bajtów. "mss 1460" oznacza że (10.10.10.10) chce otrzymać nie więcej niż 1460 bajtów w każdym zadanym pakiecie z adresu (192.168.0.1).

Następny w kolejności "nop" jest prostą instrukcją (pad), która właściwie nic nie robi, używana jest czasami do opóźniania operacji. "sackOK" odwołuje się do wybranych potwierdzeń informując, iż może być użyty dla danej sesji. Obie wartości "sackOK" i "mss" powinny być widoczne tylko i wyłącznie podczas porcji SYN, SYN/ACK wymiany TCP/IP handshake, nie powinny się pojawić w porcji danych całej sesji. Ostatnią metryką jest "win 8760" związany z ilością miejsca pamięci bufora (w bajtach), którą dysponuje adres źródłowy (10.10.10.10). Wartość ta nazywana jest czasami buforem odbioru (ang. Receive buffer). Możemy stwierdzić, iż powyższy pakiet jest pakietem SYN, gdyż widzimy na wykazie "S," lecz bardziej definitywnie dopatrujemy się klasy pakietu po jego wartości hex wynoszącej 02. Hex jako 0x.... wskazuje że następujące po nim liczby przedstawione są w formacie szesnastkowym. Przyjrzyjmy się teraz dokładniej pakietowi SYN i offsetom w których się znalazł (nagłówek TCP).

OBJAŚNIENIE FLAG TCP

Czterema bazowymi protokołami omawianej tematyki są IP, TCP, UDP i ICMP. Jeśli chcemy zliczyć bajty w rdzeniu nagłówka pakietu musimy zacząć od 0 nie od 1, jak ma to czasami miejsce. Flagi FIN, SYS, RST, PSH, ACK, URG znajdują się w 13-stym bajcie offsetu licząc od 0 w nagłówku pakietu TCP. Każda z tej flagi posiada przydzieloną dla siebie wartość, niezależnie od systemu liczbowego w którym jest przez Ciebie przedstawiana zawsze wynosi tyle samo. To z kolei daje nam możliwość zapisania maski bitów do pliku binarnego (loga), lub bezpośredniego zrzutu z tcpdump.


Diagram przedstawiony powyżej obrazuje decymalne wartości dla poszczególnych flag w 13-stym bajcie offsetu nagłówka TCP. Z takimi informacjami możemy bez problemu zaplanować filtr BPF zawierający maskę bitów i wyciągnąć wszystkie pakiety wraz z odpowiadającymi im flagami. Na przykład (korzystając z powyższego diagramu) jeśli chcielibyśmy zapisać wykaz z filtrem BPF i bitmaską tak, aby wyświetlała nam tylko pakiety PSH/ACK wykorzystalibyśmy poniższą metodę:


Podnosząc wartości obu flag ACK i PSH doszliśmy do wartości decymalnej równej 24, . Dlaczego łącznie akurat 24? - Gdyż nakazaliśmy tcpdump aby spojrzał w nagłówek TCP do 13-stego bajtu offsetu licząc od 0, sprawdził czy bajt ten posiada dziesiętną wartość równą 24 i w rezultacie wyświetlił ją nam. Pamiętajmy o tym że pracę filtru wykonuje się na pliku binarnym, który został uprzednio całkowicie zalogowany (obrazek poniżej). Filtru przedstawionego powyżej użylibyśmy celem nakazania tcpdump zapisywania tylko pakietów z powyższego IP włączając kombinację flag równą 24. Natomiast filtrem przedstawionym poniżej podziałamy na istniejący już plik binarny (log) który nazwaliśmy "bleh".


Zakładamy że plik "bleh" jest zalogowanym uprzednio zapisem sesji pomiędzy dwoma przyjętymi adresami IP. Posiadając taki plik binarny mamy możliwość dodania przeciwko niemu interaktywnie filtra bpf/bitmaski. Wykonując powyższą komendę, nakazujemy tcpdump aby przyjrzał się przyjętym warunkom, zapisując ostatecznie całą zawartość w formacie ASCII do pliku "bleh2". Pamiętajmy że zawsze lepiej jest logować bezpośrednio do pliku binarnego, który daje nam potem możliwość zrzucenia zawartości do formatu ASCII. Pliku binarnego z formatu ASCII już nie odtworzymy, a więc wniosek jest oczywisty. Wiele narzędzi takich jak Snort czy Tcpdump będzie pracowało tylko z plikami binarnymi i definitywnie odrzucą parsowanie plików w formacie ASCII.

WRACAJĄC DO BADAŃ PAKIETÓW

Przyjrzyjmy się drugiemu pakietowi:


Drugim krokiem w procedurze handshake jest SYN/ACK. Zauważyć możemy ISN +1 (podkreślone na ilustracji). Posiadamy dodatkowo numer sekwencyjności TCP - 727167800:727167800.

Przejdźmy do kroku trzeciego:


Pakiet ten jest ostatnim krokiem całości 3-stopniowej procedury. ACK oznaczony jest jako "." (zaraz za portem docelowym 25 adresu IP). ACK, następuje w formie numerów nie wskazując jako iż jest 13-stym bajtem offsetu nagłówka TCP licząc od zera, więc w rzeczywistości jest to numer potwierdzenia + 1, następują po nim kolejne numery. To jest ważny punkt do zapamiętania.


Mamy teraz nasz adres (192.168.1.1) wysyłający dane, na co wskazuje nam "P" z powyższego obrazka a także wartość 13-stego bajtu dla flagi ACK. Zauważmy że 13-sty bajt w nagłówku TCP to tam gdzie znajdują się wszystkie flagi: SYN, ACK, RST, FIN, URG, PSH. Zdajemy sobie sprawę również z tego że nie mamy możliwości wizualizacji reprezentacji flagi ACK w nagłówku pakietu na powyższym obrazku, ale widać go w bajcie 5018. Dokładniej, "18" w hex, który reprezentuje 24 w dec. Liczba ta odwołująca się do PSH i ACK jest sumowana i wynosi 24.


W pakiecie tym widzimy adres (10.10.10.10) uzyskujący odpowiedź, potwierdzając jednocześnie przyjęcie porcji danych, czyli pakietu przedstawionego powyżej. Pole z numerami zapytania zostały podkreślone na obrazku. Spoglądając na numer potwierdzenia 727167830 wiemy jednocześnie że adres (192.168.1.1) otrzymał kompletną zawartość pakietu.


Kluczowym do zapamiętania tutaj jest fakt że numer "ACK" zadanego pakietu jest kolejną oczekiwaną sekwencją numerów TCP, które pasują numerom "ACK" pakietu przedstawionego dwa obrazki wyżej. Jest właśnie tak jak powinno być. Pakiet przedstawiony na powyższym obrazku to ten który odpowiada, przyjmując zapytanie pakietu a nie ten, który wysyła dane (gdyż brak numerów sekwencyjnych). Jeśli dochodzi do wysyłania danych automatycznie warunkuje to załączenie numerów sekwencyjnych. Jeśli pakiet wysyła dane posiada on oba numery, sekwencyjny i numer "ACK". Także możemy oczekiwać że adres (192.168.1.1) wykorzysta numery "ACK" jako przyjęte numery sekwencyjne TCP.


W tym pakiecie adres (192.168.1.1) przyjmuje od pakietu z poprzedniego obrazka tylko potwierdzenie. Dlatego nie zawiera numeru sekwencyjnego TCP. Upewnijmy się, przyglądając się numerowi sekwencyjnemu z poprzedniego obrazka i żauważmy że numer ten znajduje się po prawej, czyli potwierdzenie numeru "ACK" naszego pakietu. Innymi słowy, pakiet mówi 'odebrałem Twoje dane i przetworzyłem je.'.


Na obrazku przedstawionym powyżej widać że posiadamy dwa numery, sekwencyjny i "ACK". Dlatego wiemy że używany jest do potwierdzenia danych jak również do wysyłania odpowiedzi. W tym przypadku nasz numer sekwencyjny TCP składa się z numeru "ACK" widzianego dwa obrazki wyżej. Sytuacja jest również taka jak powinna być. Zapamiętajmy że numer "ACK" pakietu jest kolejną oczekiwaną sekwencją numerów TCP przez pakiet innego adresu IP. Mamy więc ten sam numer "ACK" i jest to prawidłowe zachowanie.


Pakiet ten jest tylko potwierdzeniem na co wskazuje "ACK". Nie zawiera numerów sekwencyjnych TCP gdyż nie było wysyłanych żadnych danych. Innymi słowy, (10.10.10.10) mówi 'dzięki 192.168.1.1, otrzymałem Twoje dane.".


W tym pakiecie widzimy oba numery, sekwencyjny TCP i numer "ACK". Dla jasności, numer sekwencyjny oparty jest na numerze "ACK". Ma to sens bo wcześniejszy pakiet był tylko potwierdzeniem odebranych danych, więc taki sam numer "ACK" widziany jest także tutaj. Mając wgląd w sytuację nie trudno wywnioskować jakim wyzwaniem musi być dla intruza chęć wtargnięcia na sesję korzystając z metody przewidywania numerów sekwencyjnych TCP.


Powyższy obrazek przedstawia kolejny pakiet potwierdzenia otrzymania danych. Oznaczenie pakietu "S" klasyfikuje go jako SYN, a oznaczenie pakiet "P" to PSH. W tym przypadku pakiet "ACK" znajduje się na diagramie jako "." (widoczny za portem adresu docelowego).

KONKLUZJA

Jest to przewodnik, którego celem jest przybliżenie szczegółów komunikacji oraz zależności pomiędzy numerami sekwencyjności TCP a numerami potwierdzeń. Pełne zrozumienie tego artykułu pomoże Ci w przypadku, w którym wymagane będą od Ciebie szczegółowe badania poszczególnych pakietów. Nawet jeśli nie, to napewno wpływnie pozytywnie na Twoją ogólną wiedzę o TCP/IP.

AUTOR

Paweł Jabłoński
http://www.gorion.org/

Dokładny adres do "Szczegółowe badanie i analiza pakietów TCP."

Artykuł jest ogólnodostępny. Przełożony z oryginału autorstwa Dona Parkera i Mike Suesa dostępnego tutaj. Obowiązują jednakże prawa własności intelektualnej. Prawo do publikacji całości, lub chociaż jego części możliwe jest tylko wtedy, gdy zawierać będzie informacje o autorze przełożenia oraz link do bazowego adresu, czyli gorion's e-security thoughts. Jeżeli poruszona tematyka jest Ci bliska, wyrażasz chęć wzbogacenia jej o swoje doświadczenia, przemyślenia oraz materiały, proszę o kontakt.

Zacznijmy od wyjaśnienia kilku pojęć.


1. FRAGMENTACJA. Jeśli pakiet jest za duży dla zasadniczego dowiązania warstwy, może on zostać podzielony przez każdy router (dopóki takie zachowanie nie jest wyłączone) na wielokrotne fragmenty. Taką sytuację nazywamy fragmentacją. System musi trzymać fragmenty w pobliżu, czekać na ich dalsze części składowe i w rezultacie złożyć w całość (czyt. reasemblacja). Pakiet/fragment powinien mieć wartość TTL większą od 1 aby przejść poprawnie przez router. W momencie kiedy router otrzyma pakiet/fragment z TTL równym 1, zmniejsza jego wartość o 1. W rezultacie wartość TTL = 0 i efektem tego jest odrzucenie pakietu/fragmentu z ICMP o treści 'Time Exceeded In Transit' (ICMP type=11, code=0).



2. PRZEKROCZENIE LIMITU CZASU REASEMBLACJI FRAGMENTU IP. Maksymalny okres czasu, w którym nie-zreasemblowany pakiet zostanie przytrzymany zanim zostanie porzucony (flushowany) zależy od systemu operacyjnego. Zauważmy że technika ta używana jest również przy 'OS fingerprinting'. Tutaj polecić mogę program p0f, autorstwa Michała Zalewskiego. IDS, który reasembluje fragmenty TCP posiada timer. Na przykład, Snort domyślnie za przekroczenie limitu czasu przeznaczonego na reasemblację fragmentów pakietu uważa 60 sekund, po których początkowy fragment zostanie odrzucony i cały potok porzucony. Wykorzystuje się do tego preprocesor Frag2 lub Frag3. Parametr upływu limitu czasu na reasemblację możliwy jest do skonfigurowania w pliku konfiguracyjnym "snort.conf".



3. BŁĄD ICMP PRZY PRZEKROCZENIU LIMITU CZASU NA REASEMBLACJĘ FRAGMENTÓW. Zgodnie z treścią RFC-792 jeśli adres składa pakiet i nie może ukończyć całkowitej jego reasemblacji z powodu brakujących fragmentów w określonym limicie czasu; odrzuca datagram wysyłając 'Time Exceeded Message' (ICMP type=11, code=1). Jeżeli fragment zero jest niedostępny, wtedy 'Time Exceeded Message' musi zostać rozesłany do wszystkich.

Przedyskutujmy różne schematy ataków, celem obejścia systemów wczesnego wykrywania. Wszystkie przedstawione scenariusze zostały przeprowadzone przez specjalistów i developerów NIDS. Pierwsze dwa przypadki ataków które opiszę, wykryte zostały przez Dan Kaminsky i są najbardziej znanymi jeśli chodzi o metody obchodzenia Snort.

PRZYPADEK 1. PRZEKROCZENIE LIMITU CZASU REASEMBLACJI IDS JEST MNIEJSZE NIŻ TIMEOUT OFIARY

SCENARIUSZ ATAKU:

Przyjmijmy że przekroczenie limitu czasu reasemblacji pakietu systemu IDS wynosi 15 sekund a monitorowanymi przez niego maszynami są systemy Linux, na których domyślne przekroczenie tego samego limitu wynosi 30 sekund. Jak widać na obrazku przedstawionym poniżej, już po wysłaniu pierwszego fragmentu atakujący może wysłać drugi fragment z opóźnieniem 15 sekund, jednakże ciągle w granicach 30 sekund.


Podczas trwania tego ataku ofiara próbuje złożyć fragmenty, które IDS podczas przekroczenia limitu czasu fragmentacji wyrzucił. Pamiętać musimy że już przy drugim otrzymanym przez IDS fragmencie zostanie on odrzucony, jako że system uprzednio stracił pierwszy fragment (Timeout). Dlatego ofiara w dalszym ciągu kompletuje reasemblację fragmentów odbierając udany atak, przy którym IDS o niczym nie wie.

PRZYPADEK 2. PRZEKROCZENIE LIMITU CZASU REASEMBLACJI IDS JEST WIĘKSZE NIŻ TIMEOUT OFIARY

SCENARIUSZ ATAKU:

Snort za przekroczenie limitu czasu na reasemblację fragmentów pakietu domyślnie przyjmuje 60 sekund. Porównajmy do Linux/FreeBSD gdzie jest 30 sekund. W tej sytuacji także możliwe jest obejście IDS'a. Jak przedstawia poniższy obrazek, zakładamy że atakujący fragmentuje pakiet celem ataku na cztery segmenty: 1,2,3,4.


Atakujący wysyła Frag2 i Frag4 z podrobioną zawartością, która zostaje odebrana przez system IDS i ofiarę. IDS czeka do momentu w którym nastąpi przekroczenie limitu czasu reasemblacji fragmentów u ofiary odrzucając początkowe fragmenty, zamykając całość w 30 sekundach.

Piękno tego ataku polega na tym że ofiara nie otrzymała jeszcze fragmentu 1 a odrzuca 'po cichu' fragmenty i nie zgłosi błądu ICMP. Następnie atakujący wysyła pakiet (1,3) jako legalną zawartość (payload). Na tym etapie ofiara posiada tylko fragmenty (1,3) gdzie system IDS posiada fragmenty (1,2,3,4). Pamiętajmy o tym że fragmenty (2,4) wysłane przez atakującego miały podrobioną zawartość. Jako że IDS dysponuje już kompletem czterech fragmentów (1,2,3,4) dokona on reasemblacji TCP. Fragmenty 2 i 4 są podrobione, także ich wyliczona suma kontrolna będzie błędna i oznacza odrzucenie przez IDS. W tym momencie ofiara posiada tylko fragmenty (1,3). Jeśli atakujący wyśle teraz ponownie fragmenty (2,4) już z prawidłową zawartością, jaką uzyskał przy poprzedniej reasemblacji odrzuconych fragmentów, IDS będzie posiadał te dwa fragmenty (2,4 z prawidłową zawartością). Ofiara natomiast posiadać będzie wszystkie cztery fragmenty (1,2,3,4) z prawidłową zawartością, co w rezultacie pozwoli na ukończenie reasemblacji, odczytanie pakietu - czyli udany atak.

ATAKI OPARTE NA TTL

Ataki tego typu wymagają od atakującego rozległej wiedzy na temat topologii sieci ofiary. Informacje takie możemy uzyskać używając takich narzędzi jak traceroute, który udzieli nam informacji o ilości routerów pomiędzy atakującym a ofiarą. Obrazek przedstawiony poniżej przedstawia schemat ataku opartego o tematykę TTL.


Jak widać na powyższym obrazku pomiędzy IDS a ofiarą znajduje się router, daje to możliwość uzyskania wystarczających informacji. Atakujący w tym przypadku przeprowadza atak dzieląc go na trzy fragmenty. Wysyła fragment 1 z dużą wartością TTL, który odebrany zostaje przez IDS oraz ofiarę. Jednakże, fragment 2' wysłany przez atakującego posiada TTL równy 1 jak również podrobioną zawartość. Fragment 2' zostaje odebrany przez IDS lecz odrzucony z wartością TTL zredukowaną do 0 przez router (sytuowany pomiędzy IDS a ofiarą).

Atakujący wysyła następnie fragment 3 z poprawną wartością TTL. To zmusza system IDS do przeprowadzenia przez IDS reasemblacji TCP z wykorzystaniem fragmentów (1,2',3), gdzie ofiara w dalszym ciągu oczekuje trzeciego fragmentu. Atakujący ostatecznie wysyła trzeci fragment już z prawidłową zawartością a ofiara reasembluje całość trzech fragmentów (1,2,3) padając celem udanego ataku. Na tym etapie IDS posiada tylko fragment 3 i ma już etap reasemblacji i flushowania strumienia za sobą.

METODA ZACHODZĄCYCH NA SIEBIE FRAGMENTÓW (NAKŁADANIE)

Istnieje jeszcze jedna ciekawa klasa ataków bazująca na przekroczeniu limitu czasu reasemblacji z wykorzystaniem nakładania na siebie fragmentów. Oczywistym jest, iż reasemblacja fragmentów wygląda inaczej dla poszczególnych systemów operacyjnych. Opierając się na tym założeniu możemy wyodrębnić pięć różnych polityk reasemblacji, których szczegółówy opis wyczytać możemy w artykule nazwanym 'Active mapping: resisting NIDS Evanion without alerting traffic' autorstwa Paxsona & Shankara. Przyjrzyjmy się w tym artykule tylko dwóm z pięciu znanych polityk reasemblacji. A dokładniej: 'pierwszej' i 'ostatniej'.

Pierwsza. To tam gdzie system operacyjny podaje oryginalny fragment z określonym offsetem. Na przykład: Windows 95/98/NT4/W2K/XP/2003. Ostatnia. Gdzie system operacyjny podaje wynikający z następstwa fragment z określonym offsetem. Na przykład: Cisco IOS.

'Pierwszą' i 'ostatnią' politykę fragmentacji przedstawia poniższy obrazek.


Atakujący przeprowadza atak rozkładając go na 4 fragmenty. Najpierw wysyła fragment 1, fragment 2, fragment 3, które oba systemy operacyjne akceptują. Następnie atakujący wysyła fragment 2', fragment 3' i fragment 4. Tutaj zawartość 2' i 3' jest różna od 2 i 3. Offset, jego długość w połączeniu z innymi polami nagłówka pakietu IP pozostają takie same. Przy takim założeniu, system operacyjny przeprowadzający reasemblację fragmentów opartą na polityce pierwszej dokona reasemblacji fragmentów 1,2,3,4. System operacyjny przeprowadzający reasemblację fragmentów opartą na polityce ostatniej zreasembluje pakiety 1,2',3',4.

Odwzorowanie polityk fragmentacji dla poszczególnych systemów operacyjnych przedstawia poniższy obrazek.


Bardziej szczegółowe opisy dotyczące polityk reasemblacji fragmentów można znaleźć w dokumentacji Snort.

PRZECIWDZIAŁANIE WYMIENIONYM TYPOM ATAKÓW UŻYWAJĄC SNORT

Snort jest niewątpliwie najbardziej znanym i powszechnie używanym systemem IDS. Dostarcza rozwiązań, które radzą sobie z metodami obchodzenia systemów wykrywania włamań odnosząc się także do ataków przedstawionych w tym artykule. Preprocesor Frag3 jest docelowym modułem defragmentującym IP w Snort. Nawiązując do wzmianki umieszczonej na oficjalnej stronie Snort.org, "Frag3 ma na celu zastąpienie modułu defragmentującego Frag2, został zaprojektowany tak aby umożliwił:

1. Szybszą pracę modułu, optymalniejsze rozwiązania przetwarzania danych.


2. Model technik anty-evasion (obchodzenie) oparty na docelowej maszynie.

Preprocesor Frag3 z implementacją polityki fragmentacji celu, która daje użytkownikowi możliwość identyfikacji metod reasemblacji fragmentów, oraz właściwą wartość przekroczenia limitu czasu dla fragmentu, który pojawił się w poszczególnym docelowym adresie IP lub podsieci. To sprawia że IDS dostarcza reasemblacji fragmentów w taki sam sposób jak zrobiłyby to na przykład różne adresy IP sieci domowej. Załóżmy że posiadamy całą sieć (192.168.0.X) która składa się tylko i wyłącznie z maszyn na OpenBSD i chcemy skonfigurować Snort tak, aby korzystał z odpowiedniej dla tej sieci polityki reasemblacji. Musimy oczywiście włączyć obsługę preprocesora Frag3 w pliku konfiguracyjnym i desygnować odpowiedni typ fragmentacji, jak poniżej:


Od tej chwili każde nakładane fragmenty, które Snort zobaczy przeznaczone dla podsieci (192.168.0.X) zostaną zreasemblowane używając polityki przeznaczonej dla 'BSD'. Pole fragmentacji przekroczenia limitu czasu zostanie automatycznie ustawione tak aby odpowiadać tej obowiązującej w systemach BSD. Podobnie, Snort zreasembluje wszystkie fragmenty przeznaczone dla podsieci (10.1.30.X) używając polityki fragmentacji 'pierwszej'. Preprocesor Frag3 daje także możliwość precyzowania pola min_ttl, w którym możemy ustawić minimalną akceptowaną wartość TTL dla fragmentu. Jeśli istnieje router pomiędzy IDS a podsiecią (192.168.0.X), wtedy określając minimalną akceptowaną wartość TTL dla fragmentu przeznaczonego dla tej podsieci jako 2, możemy zapobiec atakom opartym na obchodzeniu z wykorzystaniem technik TTL.

KONKLUZJA

Pozdrowienia dla Sumit Siddharth, Network Intelligence India (NII) za inspirację, bez niego nie byłoby tego artykułu. Reasumując, przyjrzeliśmy się w nim kilku typom ataków skierowanym w IDS, różnych metodologii zawartych w poszczególnych technikach. Powaga sytuacji oraz obowiązkowa wiedza na temat różnorodności przeprowadzania reasemblacji fragmentów w różnych systemach operacyjnych jest oczywista. Dowiedzieliśmy się również, iż atakom tego typu zapobiec można wykorzystując silnik preprocesora Frag3 w programie Snort, oraz poprawnej jego konfiguracji. Scenariusze różnych ataków zaprezentowanych w artykule są rezultatem analiz w oparciu o różne metody obchodzenia systemów IDS. Ukazana została również istota i powaga mechanizmu reasemblacji opartej na nakładaniu fragmentów, oraz przekroczenia limitu czasu przy reasemblacji w różnych systemach.

AUTOR

Paweł Jabłoński
http://www.gorion.org/

Dokładny adres do "Metody obchodzenia systemów IDS na przykładzie Snort NIDS."

Artykuł jest ogólnodostępny. Przełożony z oryginału autorstwa wspomnianego już Sumita Siddharta dostępnego tutaj. Obowiązują jednakże prawa własności intelektualnej. Prawo do publikacji w obecnej formie całości artykułu, lub chociaż jego części możliwe jest tylko wtedy, gdy zawierać będzie informacje o autorze przełożenia oraz link do bazowego adresu, czyli gorion's e-security thoughts. Techniki obchodzenia IDS będą przeze mnie w dalszym ciągu rozbudowywane, jeżeli jesteś zainteresowany współpracą na tej płaszczyźnie, proszę o kontakt.

REFERENCJE

1. Autor oryginału, Sumit Siddharth, Network Intelligence India (NII)


2. Insertion, Evasion and Denial Of Service: Eluding Network Intrusion detection System


3. RFC-792, Narzędzie traceroute, Snort Frag3


4. p0f - OS fingerprinting tool, Michał Zalewski


5. Active Mapping: Resisting NIDS Evasion Without Altering Traffic