WPROWADZENIE Rozważamy własności zachowania (behaviour) rozproszonych systemów reaktywnych, których przykładem są systemy telekomunikacyjne, tu zwłaszcza sieci pakietowe (w semantycznym skrócie: Internet)

Pełen tekst

(1)Krzysztof M.Brzeziński Instytut Telekomunikacji Politechniki Warszawskiej ul.Nowowiejska 15/19 00-665 Warszawa e-mail: kb@tele.pw.edu.pl. 2006. Poznańskie Warsztaty Telekomunikacyjne Poznań 7 - 8 grudnia 2006. JĘZYK TTCN-3 A BIERNE WYKRYWANIE ATAKÓW SIECIOWYCH Streszczenie: W niniejszej pracy rozważono możliwość zastosowania języka TTCN-3, i skojarzonego z nim mechanizmu wykonawczego, do zapisu i realizacji testów biernych, na przykładzie problemu wykrywania ataków włamań sieciowych. Dokonano tym samym rozszerzenia obecnego paradygmatu, wiążącego język TTCN-3 z testowaniem czynnym (aktywnym).. 1. WPROWADZENIE Rozważamy własności zachowania (behaviour) rozproszonych systemów reaktywnych, których przykładem są systemy telekomunikacyjne, tu zwłaszcza sieci pakietowe (w semantycznym skrócie: Internet). W tej dziedzinie szczególnie widoczny jest podział na "kultury" telekomunikacji tradycyjnej i nowej. Ta pierwsza, zakorzeniona m.in. w międzynarodowej, rozważnej standaryzacji protokołów sygnalizacyjnych (ITU-T i ETSI), w zassadniczy sposób przyczyniła się do rozwoju formalnej metodyki i narzędzi weryfikacji i walidacji, także z użyciem rygorystycznego testowania. Kultura nowa, charakterystyczna dla środowiska internetowego i para-standaryzacji prowadzonej w ramach IETF, z jej często cytowanym mottem: "rough consensus and working code", jest bardziej skłonna do przyjmowania rozwiązań ad-hoc. W każdej z tych kultur rozważa się analogiczne problemy (występujące obiektywnie, gdyż wynikające z istoty telekomunikacji), używając do tego własnego, często hermetycznego aparatu pojęciowego, do którego niechętnie są włączane dokonania "drugiej strony". Taka sytuacja, wynikająca także z wzajemnej nieświadomości tych dokonań (patrz odniesienia do literatury w publikowanych pracach), prowadzi do chaosu i marnotrawstwa wysiłku. Niniejsza praca ma w zamyśle stanowić krok w kierunku generalizacji i harmonizacji metodyki stosowanej przez obie kultury. Pokażemy, w jaki sposób koncepcje i narzędzia dotyczące testowania, opracowane i poddane standaryzacji w ramach prac środowiska tradycyjnie telekomunikacyjnego, mogą zostać z pożytkiem zaaplikowane w środowisku telekomunikacji nowej. Przedmiotem rozważań będzie język zapisu testów TTCN-3 (Testing and Test Control Notation) [1], zastosowany do ciągłego (on-line) monitorowania ruchu pakietów w pewnym przekroju pracującej sieci i orzekania o własnościach tak obserwowanego. zachowania systemu rozproszonego. Testy, jakie są przy tym wykonywane, mają charakter bierny. Celem prowadzenia takich testów będzie tu wykrywanie włamań / ataków sieciowych (intrusion detection) - jedno z podstawowych wyzwań telekomunikacji nowej. Zaproponowane idee wydają się służyć obu środowiskom: poszerzają paradygmat użycia języka TTCN (a więc mogą przyczynić się do osiągnięcia masy krytycznej jego zastosowań), a do zbioru metod i narzędzi używanych w środowisku "internetowym" (w większości wąsko specjalizowanych) dodają rozwiązanie ogólne i standaryzowane. 2. STAN SZTUKI. Wykrywanie włamań (Intursion Detection) Konstrukcja systemów wykrywania włamań IDS (Intrusion Detection Systems) jest przedmiotem obszernej i łatwo dostępnej literatury [2]. Dlatego, dla kompletności, jedynie podsumujemy najistotniejsze fakty. Powszechnie akceptowany jest podział generalnej koncepcji budowy systemów IDS na trzy klasy [3]: a) misuse detection (także signature-based, knowledge-based): wykrywa się wzorce ("sygnatury") znanych ataków; b) anomaly detection (także behavior-based): wykrywa się odstępstwo od ruchu "normalnego", zwykle poznanego w wyniku samo-uczenia i zwykle wyrażanego za pomocą miar statystycznych; c) specification-based: wykrywa się odstępstwo od zachowania poprawnego, którego opis wprowadza się z zewnątrz. Z niejasnych powodów, wszystkie opisy tej koncepcji sugerują, że chodzi o specyfikację, którą trzeba opracować od podstaw i która nie ma wiele wspólnego ze specyfikacją projektową systemu [4]. Z uwagi na powiązanie z systemem poddanym obserwacji, wyróżnia się systemy IDS typu: a) host-based: takie, które informację o zdarzeniach otrzymują (np. w wyniku instrumentacji kodu); b) network-based: takie, które odtwarzają informację z obserwacji medium transmisyjnego. Do zadania własności zachowania potrzebny jest odpowiedni język (notacja, formalizm, mechanizm). Wśród niezwykle licznych i różnorodnych rozwiązań w tym zakresie, wymienić można: automaty EFSM [5],.

(2) język wyrażeń regularnych REE [6], BMSL (Behavioral Monitoring Specification Language) [7], samokonstruowane automaty stanowe FSA [8], gramatyki PE (Parallel Environment) [9], ADL (Agent Development Language), STATL (Attack Language for State-based Intrusion Detection) [10], ASL (Auditing Specification Language) [11], język Bro, NERL (Network Event Recognition Language) [12].. Język TTCN Historię powstania i konstrukcje języka TTCN-3 przedyskutowano w [13, 14, 15]. Jednakże, z uwagi na tezy niniejszej pracy, (zwłaszcza na potrzebę przezwyciężenia opinii o hermetyczności języka) celowe tu będzie dokładniejsze wprowadzenie. Aktualna (w chwili pisania niniejszego) wersja standardu ETSI dla języka TTCN-3 (seria ETSI ES 201 873-x, edycja 3.1.1, wydanie 2006-06-21) obejmuje siedem tomów: 1 - Core Language, 2 - Tabular presentation Format (TFT), 3 Graphical presentation Format (GFT), 4 - Operational Semantics, 5 - Runtime Interface (TRI), 6 - Control Interface (TCI), 7 - The use of ASN.1. Język TTCN-3 służy do wyrażania konfiguracji i zachowania abstrakcyjnego systemu testowego (rys.1), złożonego ze zbioru mogących działać współbieżnie komponentów testowych TC: jednego głównego (MTC, Master Test Component) i potencjalnie wielu komponentów równoległych PTC (Parallel Test Component). Komponent jest charakteryzowany przez zbiór swych portów. Poprzez porty dokonywane są akty komunikacji, które polegają na przesyłaniu wiadomości (message) i wywoływaniu procedur (procedure).. Rys.1. Abstrakcyjny system testowy TTCN-3 Program zapisany w języku TTCN, czyli zestaw testów abstrakcyjnych ATS (Abstract Test Suite) definiuje konfigurację komponentów testowych i zachowanie tychże dla każdego z testów zestawu. Konfiguracja testowa jest tworzona w wyniku dynamicznego kreowania ( create ) instancji komponentów testowych oraz łączenia (connect) wskazanych portów komponentów między sobą i przydzielenia (map) portów komponentów MTC/PTC do portów abstrakcyjnego interfejsu systemu testowego ATSI. Te porty są jedynym mechanizmem komunikacji. programu testu z implementacją testowaną (SUT) / systemem testowanym (IUT). Ponadto, komponenty testowe mogą komunikować się ze sobą za pomocą połączonych portów, dla celów koordynacji testu. Jednostką zapisu w języku TTCN-3 jest moduł, składający się z części definicyjnej i części sterującej. Część definicyjna zawiera definicje typów danych, stałych, szablonów (template), portów, komponentów testowych (zbiorów portów), funkcji i testów (test case). Syntaktycznie, test jest opisem zachowania komponentu głównego MTC. Dynamicznie, komponent MTC może kreować i startować wiele komponentów PTC, a każdy z nich - może z kolei kreować i startować dalsze komponenty PTC, których zachowanie jest definiowane jako funkcja. Część sterująca modułu zawiera program wywołań poszczególnych testów zbudowany z klasycznych instrukcji strukturalnych, uzależniających wykonanie dalszych testów od werdyktu wcześniejszego. Look-and-feel podstawowej notacji tekstowej języka TTCN-3 (core notation) jest zbliżony do wysokiego poziomu języków programowania, czym różni się od wersji wcześniejszych, uważanych za "ezoteryczne" i trudne do przyswojenia dla programistów. Pozostałe, równoważne notacje języka (tabelaryczna TFT i graficzna GFT) nie są popularne. Pomimo upodobnienia do znanych języków programowania ogólnego zastosowania, TTCN pozostaje językiem zaprojektowanym do zapisu szczególnego rodzaju programów - testów. W tym celu język definiuje syntaktykę i semantykę specyficznych konstrukcji, m.in.: (a) operacje nadawania (send) i odbioru (receive) na określonym porcie; (b) template (szablon, wzorzec): specjalny rodzaj stałej bądź zmiennej wskazanego typu, która może przyjmować wartości niedookreślone. Szablonu używa się do wskazania konkretnej wartości w operacji nadawania bądź zbioru wiadomości w operacji odbioru: wiadomość zostanie zaakceptowana tylko, jeśli należy do tego zbioru ("pasuje" do szablonu). Dla celów posługiwania się szablonami wprowadzono operatory, atrybuty i pseudo-wartości symboliczne. Z tymi instrumentami notacyjnymi związane są mechanizmy dopasowania (matching mechanisms), zdefiniowane jako część semantyki operacji odbioru i nadawania. Na przykład, operator '?' (AnyValue) występujący w szablonie zamiast pewnej części składowej jego typu (np. zamiast pola rekordu) spowoduje, że przy odbiorze zostanie zaakceptowana wiadomość przenosząca w tym polu dowolną wartość. Operator '*' (AnyValueOrNone) dodatkowo dopuszcza sytuację, w której wiadomość w ogóle nie zawiera tego (opcjonalnego) pola. (c) timery; upłynięcie timera jest stwierdzane w wyniku wykonania operacji o charakterze zbliżonym do instrukcji odbioru. Pragmatyka stosowania timerów obejmuje m.in. zapewnienie skończonego czasu wykonywania testu i badanie czasu odpowiedzi SUT na nadane pobudzenie [16]. (d) zachowanie alternatywne (alt): lista alternatyw, z których każda składa się z operacji i następującego po.

(3) niej bloku instrukcji. Po wejściu do bloku alt następuje próba skutecznego wykonania operacji poszczególnych alternatyw, w kolejności ich podania w tekście programu. Jeśli wykonanie żadnej z tych operacji nie jest możliwe w danym stanie środowiska testowego, wówczas następuje ponowne wejście do bloku alt, z uaktualnioną "zamrożoną" informacją o tym stanie. Z pragmatyki stosowania języka wynika, że w bloku alt występuje najczęściej pojedyncza alternatywa z operacją nadawania (pobudzenie) lub zestaw wielu alternatyw z operacjami odbioru (oczekiwanie na jedną z alternatywnych odpowiedzi) i operacjami timeoutu (wykonywanymi skutecznie w wypadku np. upłynięcia maksymalnego dopuszczalnego czasu oczekiwania na odpowiedź). (e) werdykty: wartości (pass, fail, inconc, none, error) należące do specjalnego typu verdicttype, które mogą być przypisywane zmiennym i odczytywane. Jednym z najistotniejszych (z punktu widzenia niniejszej pracy) aspektów metodyki TTCN jest to, że standaryzacji podlega także architektura systemu testowego (w sensie informacji realizacyjnej). W domenie implementacyjnej, porty ATSI są we "właściwy" sposób połączone z SUT. Technologia takiego połączenia, ukryta przed programem testu, jest przedmiotem części 5 standardu, definiującej interfejs TRI (TTCN-3 Runtime Interface), który służy rzede wszystkim do komunikacji z adapterem systemu testowanego SA (SUT Adapter). Ścisłe określenie funkcjonalności i interfejsu tego adaptera (wraz z odwzorowaniem w popularne języki programowania) sprawia, że adaptacja systemu testowego do konkretnego systemu testowanego stała się rutynowym zadaniem programistycznym. Podobnie, wydzielono funkcje i interfejs bloku koderów/dekoderów CD (część 6 zbioru standardów, definiująca interfejs TCI). 3. MOTYWACJA I PRACE ZWIĄZANE Pierwotnie, język TTCN stanowił integralną część przemysłowej metodyki testowania zgodności ( c o n f o r m anc e ) implementacji protokołów telekomunikacyjnych [17], która dotyczy zachowania logicznego jednostek protokołu i w sposób jawny wyklucza ze swego zakresu kwestie wydajności (performance), odporności (robustness), skalowalności, obciążalności i innych istotnych, poza-logicznych własności systemu. W naturalny sposób, środowisko skupione wokół języka TTCN-3 dążyło do jego rozwoju. Te dążenia były realizowane m.in. poprzez proponowanie eksperymentalnych zmian w języku, takich jak: konstrukcje dla testowania wydajności (performance) PerfTTCN [18], TimedTTCN-3 [19]; własności czasu rzeczywistego (real-time) - Real-Time TTCN [20], [21]; obsługa testowania współpracy (interoperability) [22]; stosowanie aplikacji zewnętrznych [23]. W niniejszej pracy rozważa się nieco inną ścieżkę rozwoju języka, dotyczącą pragmatyki jego stosowania. Wszelkie wyżej wskazane zmiany zachowywały zasadniczy paradygmat testowania aktywnego, którego. istotą jest: pobudzanie SUT (control), obserwowanie odpowiedzi na te pobudzenia (observation) i ocenianie tak sprowokowanego zachowania (wydawanie werdyktu). Odpowiednio, porty interfejsu ATSI były we wcześniejszych wersjach języka wprost określane jako PCO (point of control and observation). Tymczasem język TTCN zostanie tu użyty do testowania pasywnego (biernego). Porty ATSI będą w tym zastosowaniu pełnić rolę PO (punktów obserwacji). Terminu "testowanie bierne" używamy tu w rozumieniu szerokim, którego istotą jest po prostu brak jawnych pobudzeń. To pojęcie występuje także w rozumieniu znacznie dokładniej zdefiniowanym [24, 25]. Propozycja wykorzystania metodyki testowania do wykrywania włamań sieciowych przewija się w wielu pozycjach literatury, ale jedynie jako hasło (np. [12]). Tymczasem potrzeba podjęcia tej idei, z zastosowaniem standaryzowanego języka i środowiska testowego, staje się nagląca choćby w obliczu niesłychanej liczby różnych, wymienionych wcześniej podejść i języków służących do "programowania" systemów IDS. Pewne elementy testowania biernego przy użyciu języka TTCN zostały przedyskutowane w [18], gdzie m.in. w ramach architektury testów aktywnych wyróżniono punkty PCO przeznaczone jedynie do obserwacji, nazywane tam measurement points (a więc w naszym ujęciu - punkty obserwacji PO). Generalną potrzebę przyswojenia przez środowisko "internetowe" technologii TTCN postuluje się m.in. w [26]. Jedynym bardziej dojrzałym prekursorem prezentowanych tu idei jest [27], gdzie rozważa się oparty na języku TTCN-3 system służący do walidacji zachowania, jakie np. towarzyszy wdrażaniu pewnej usługi. Występuje tam m.in. idea próbników (probes) - obiektów zbliżonych do punktów PO. Jednakże ewentualne zastosowanie takiego systemu do wykrywania włamań zostało jedynie zasygnalizowane jako potencjalny temat dalszych prac. 4. EKSPERYMENT Z JĘZYKIEM TTCN-3 Zgodnie z ideą naszkicowaną wcześniej, zrealizowano w języku TTCN-3 testy bierne m.in. dla ataków Ping of Death, Smurf i Neptune [28]. Zostanie tu przedstawiony jedynie bardzo prosty eksperyment dotyczący ataku Smurf, przeprowadzony w komercyjnym środowisku rozwojowym TTCN-3 firmy OpenTTCN. Atak znany jako Smurf jest atakiem sieciowym typu flooding DoS, czyli takim, w którym atakowany jest zalewany żądaniami generowanymi z inicjatywy atakującego, co prowadzi do wyczerpania zasobów wymaganych do realizacji misji systemu. Atakujący wysyła zmodyfikowane pakiety echo request protokołu ICMP (Internet Control Message Protocol) [29], używając do tego adresu rozgłoszeniowego (broadcast), a nie indywidualnego adresu konkretnego odbiorcy. Pakiety te zawierają, w polu nadawcy, adres atakowanego - adres atakującego nie jest ujawniany (nie pojawia się w nagłówkach generowanych pakietów). Każdy odbiorca rozgłaszanego pakietu odpowiada pakietem ICMP: echo reply skierowanym do.

(4) atakowanego, który zostaje tym samym "zalany" nieoczekiwanymi odpowiedziami. Zastosowany algorytm wykrywania ataku Smurf zostanie dalej opisany w jednoczesnym odniesieniu do jego zapisu uogólnionego (rys.2) i jego implementacji w języku TTCN-3 (rys.3). Przykładowe oznaczenie (3/7) kieruje do linii 3 algorytmu i linii 7 programu TTCN-3. ' H a t § Ó ó. PQ Pa P2k.

(5)

(6)

(7) "! # $ % # % & ()+*, - . / 02134 365 7"198 8 :;<;+=2>? @A<BCD EF;G D B IJ K LMNOP KQ R SUT VWX YZ[ LX [ \U] ^_` _ a bc de f ghi jk lmn oqprph s uv+wx y z { |2}~ ~6 "}9 " A ¡ ¢£¤ ¡ ¤ ¥U¦ ¨ © ª «¬ ®¯ °±²q³µ´F¶·¶F¸ ¹Fº¼» ½ ¾¿ÀÂÁ½ ÃÄ Å ÆÇÈ ÉÊ ËÌÍ ÎÏ ÐÊ Ñ Ò Ô Õ Ö×Ø ÙÚ ÛÜÝqÞFß6Þ·à2á â ãäåÂæâ çè é êÛÜ ëì ÖÚí îqïðññ ò ôõ+ö÷ ø ù ú û2üýþ ý6ÿ "ü.

(8) ! "#$%&'( #)* +, -." /01 $2" 1 354 6 7 , $&89:" #( ;=<?>A@B@AC DAEF4 G H I!KJG L , 0:#( -1 $2"M / N O1 * 4 R S TUVW:X YZ [=\A]\B^`_ b c de f:YZ gh T2Xi j=h WTUWT dl md f:YZ gh T2Xi j n oh p Rys.2 Algorytm wykrywania ataku Smurf. Tester oczekuje na wystąpienie początkowej wiadomości, która mogła być wysłana przez atakującego: echo request z adresem rozgłoszeniowym (1/59). Następnie, aż do wydania werdyktu, przedmiotem zainteresowania są wyłącznie pakiety echo reply, potencjalnie wysyłane w odpowiedzi na wiadomość początkową, czyli opatrzone adresem przeznaczenia równym podanemu adresowi atakowanego (3,6,10/24,31,44). Parametrem testu jest czas detekcji ataku DET_TIME. W pierwszej fazie, oczekuje się przez ten czas na odebranie pierwszego pakietu odpowiedzi. Jeśli taki pakiet nie pojawi się (a więc atak nie zostanie podchwycony), wówczas test kończy się werdyktem jałowym - none (4/23). W przeciwnym przypadku rozpoczyna się faza druga, w której pakiety odpowiedzi są zliczane. Jeśli w zadanym czasie ich liczba przekroczy (dużą) wartość MASSIVE, wówczas test jest natychmiast kończony z informacją o wykryciu ataku - werdykt fail (7/33). Jeśli po upłynięciu czasu zliczania ich liczba nie przekroczy pewnej (niewielkiej) wartości progowej USUAL, wówczas wnioskuje się, że atak mógł zostać podjęty, ale nie rozwinął się do postaci niebezpiecznej werdykt pass (8/30). Jeśli natomiast liczba odpowiedzi będzie "umiarkowana", przechodzi się do fazy trzeciej, w której odpowiedzi są ponownie zliczane. Podobnie jak w fazie drugiej, stwierdzenie bardzo dużej liczby odpowiedzi natychmiast kończy test z werdyktem fail (11/46). Natomiast ocena sumarycznej liczby odpowiedzi uzyskanych po zadanym czasie jest odmienna: jeśli zliczono ich mniej niż wartość progowa, wówczas wydaje się werdykt "ostrożny" (inconc) - być może atak trwa (13/42), a jeśli więcej (umiarkowana liczba odpowiedzi utrzymuje się w kolejnym odcinku czasu) werdykt fail (14/43). Omówiony wyżej algorytm jest realizowany w standaryzowanej architekturze systemu testowego (por. rys.1). Dalsze odniesienia dotyczą wierszy tekstu programu TTCN-3 z rys.3. Konkretne użycie elementów. architektury, wraz z zachowaniem testera, jest zapisane w module TestSmurfAttack (1). Test o nazwie SmurfSearch (51) definiuje zachowanie głównego komponentu testowego (MTC), tu - komponentu o nazwie Sniffer (10). Ten komponent posługuje się portem p (9), zdefiniowanym jako jednokierunkowy port wejściowy dla wiadomości typu Icmp (5). Z chwilą startu testu domyślnie kreowany jest komponent Sniffer, który zaczyna wykonywać zachowanie określone w (52..62). Port p jest przydzielany do portu interfejsu systemu testowego (58). Operacja odbioru wiadomości pasującej do szablonu broadcast_request z kolejki portu p (59) jest blokująca jej semantyka jest równoważna semantyce bloku alt z jedną tylko alternatywą, która jest "próbowana" w pętli do chwili powodzenia, czyli tu - do odebrania wiadomości atakującej. Po odebraniu takiej wiadomości, wydobywa się z niej wartość pola adresu "nadawcy" src, czyli adresu użytkownika zaatakowanego (60). Z tym adresem wywoływana jest funkcja TrackPings (61), w której realizuje się dalszą część algorytmu. Z chwilą powrotu z tej funkcji werdykt testu jest odczytywany (62), a dla werdyktu fail - raportuje się wykrycie ataku i podaje się adres atakowanego. Test wykonuje się w pętli zadanej przez część sterującą modułu (64), aż do chwili uzyskania werdyktu fail (czyli wykrycia ataku). Funkcja TrackPings (12) posługuje się innym szablonem (16), do którego "pasują" odpowiedzi stanowiące o istocie ataku. Dla ścisłości, w przykładzie zastosowano tu "zmienną szablonową" var template, a nie szablon template; ta konstrukcja, dostępna począwszy od obecnego wydania standardu dla języka TTCN-3, stawia mniej ograniczeń np. przy dynamicznej parametryzacji szablonu (18). W każdej fazie, przebieg testu jest zadany przez oddzielny blok alt. Alternatywy każdego z tych bloków służą do stwierdzenia upłynięcia czasu wykrywania (23,30,41), odbierania odpowiedzi oczekiwanych (24, 31, 44) oraz odbierania wszelkich innych, nieoczekiwanych pakietów (25, 35, 48). Czyni się użytek z instrukcji repeat, powodującej natychmiastowe ponowienie wykonania bloku alt oraz z instrukcji return, powodującej powrót z funkcji.. q rKst uv w xFyz{ |} ~ B{ { ` AB`K ¡ ¢ £?¤A¥B¥A¦ §A¨ª© «¬® ¯ °± ² ³´µ ¶ ±·´ ¸`¹º»º¼ ½ ¹ª¾ ¿ÀÁÂ ÁÃ Ä Å ÆÇ È=É ÈÊË É Ì Í ÎÏ Ð5Ñ Ò ÓÔ ÕÖ ×Ø Ö Ù Ú Û ÜÝ Þß à áâ ãä åæ ä ç è é êëì í î ï ðñ òóòô õ?ö÷ø ùúû ü ý þ ÿ ÿ

(9) . !#" $ %'& ( )*+,-*,( .0/1 2 2 345 678 9 : ;

(10) <=>?4 @>ACB D D 9 E6FG7H-67IFI9 <KJ'L.M:'5 678 9 : ;

(11) <=>?4 @>ACB D'N O P IGQ9 R 7I ST UVW'XY ZC[\#] ^ _`abc dQe c ^ _f gQh ikjlmmh n o'p q rstus v0wx y y zh{ ok| } ~ 'C ' 0 ' } ~ - ~Q #¡¢C£'¤

(12) ¥¦§ ¨© ª'« Q¬ ®°¯ ±²³ ´'µ Q¶ ¬'·¯ ±°¬Q ®k¸¹¶¶ ³ ´'º » ¼'½¾ ¿QÀÁ-Â ÃÄÅ Æ'Ç Ç ÈÉkÊË°Ì ÈÍÎ Ï K ÐÑ Ò Ò Ó Ó Ó ÔÕ ÖQ× Ø0ÙkÚÛÜ ÛÚÛ.

(13)

(14)

(15) :; X Y i j l m x y º » º Ç Õ Õ ýþ. ! " #$ %&" ' (*)+ +,*-. /*- 0 1 2 34.65 78 7- 9 < =6>6? @ A B A C D6A E F G*HJILK M N O6P Q RS T U V*W Z [6\6] ^ _ ` _ a b6_ c ^ _ d6_ ef g*h k n n o o o pq rs6tvu twt z { |} ~ } J * 6 ¢¡£¥¤§¦¨ © ª «¬ 6« ® ¯ ° ±¬ ² ³6´ ª ª µ ¶ ® «¬ ·&® ¸ ¶*¹ ¹ ¼ ½6¾6¿ ® « ± « ° 6« ² À Á*ÂJÃLÄ Å µ Æ ÈJÉ Ê Ë*Ì Í Î&Ï ÐvÈJÉ Ê Ë*Ì Í Î6ÑÓÒÔ Ö × Ø ÙJÚ Û Ü*Ý Þ ß6à áãâ¢ä¥ä¢å æ¢çè é ê ëì í6ë î ï ð ñì Ø ò ó ð ô è õ ö ÷ø ù&ö ú û*ü û ÿ * ÿ

(16) .

(17) . . ! "$# %& %!!%. ' ( ) * +

(18) , -. , /. ' 0 1324 5) 6798 :;/ < ; -= , > < ? @ A B!) * , C DFE G@H , > <I C J K 1324 5) 67LNMPOQMSRUT!V> + E

(19) , WE. X@C Y

(20) , K C ZY G@ZY V /[ <' E= + E > + E

(21) , WE. X@C Y

(22) , K J -C = V /[[ < < A B\* . E Y EC WE K ]5^3_`67 V> <a 1324 5) 6798 :1324 5) 67bc?!/ <d C J K 1324 5) 67eNfgRPOSOPh iPjkV> + E

(23) , WE. X@C Y

(24) , K J -C = V /[ <l E= + E > . EmE -

(25) , /[[ <( A B\* . E Y EC WE > . EmE -

(26) , /[ <0 [ n oqpr r st!uwv x t!y$z { |t nk} ~

(27) ~ Q @ !w 9@ Q

(28)

(29) g3 @P3 ¡ ¢£¤ ¥ ¦!§¨©!¦3ª

(30) «3¬ ® ¯° ±!²³ ´ µ ¶·¸ ¹º»¼ ½

(31) ¾ ¼ ¿ ÀÁ Â

(32) Ã Ä$Å Ã ÆÇ È

(33) É Ê»¼¾ ËÌÎÍ9Ï »

(34) ¾ Ë Ð Ñ!ÒÓÔ Õ Ö × Ø Ñ3×

(35) Ù3Ú Û9Õ Ü ÝÞ!Ü

(36) Ù3Ú9ß àá â â ã

(37) ä åwæ çèé ê ë ì

(38) í3î9ï ðNñ!ò

(39) î î óô õwö ÷ ø ù ùö ú ù û ügý3þ ÿ

(40) . !#" $ %&#' ( ) *+ %,%- &# ) *. / 0 *1 2 &3&#4 5& $ 67 89:;9<= >?7 @A#B@<= .#C D 5#' E& 6;9<= >F 8#BG:#/ H I JK ;= K L ) MN6;9<= >F 8#BG:?1 <7 ;/ H O

(41) PRQ STUVRW XYZ[ \W T] W ^`_ a bc d e [ f?gh ig#j kld mh nn e o#d p _#q p r?f s t uwv xy z{#| }#y ~~ } ~ v `t

(42) ~ v` l l ? ¡?¢ £ ¤ ¥ ¦§¦¨#©ª ¦ « ¬w ®¯ ° ¬l±²#¯ ³´« µ µl¶ · ¸ ¹#º » µ ¼½ ¾¿½À À ÁÂÃÄ!ÅÃÆÇ Á. Rys.3. Program testu w języku TTCN-3 Konstrukcja testu przewiduje oczekiwanie na pierwszą wiadomość atakującą, a następnie analizowanie odpowiedzi na tę i tylko tę wiadomość, aż do chwili wydania werdyktu. Wprawdzie test jest cyklicznie ponawiany, lecz system IDS pozostanie "ślepy" na ataki inicjowane przez wiadomości atakujące, odbierane poza fazą początkowego oczekiwania. Aby takiej sytuacji uniknąć, można test rozproszyć (rys.4(b).. Rys.4. Warianty konfiguracji testu. Poza głównym komponentem MTC Sniffer, definiuje się inny typ komponentu: Analyser, na którym wykonuje się funkcja TrackPings (z klauzulą: runs on Analyser). MTC oczekuje teraz na wiadomości atakujące, a dla każdej takiej wiadomości - natychmiast kreuje egzemplarz komponentu równoległego PTC (...Analyser.create), łączy własny port wewnętrzny w z portem tego komponentu (connect...:w,mtc:w) i startuje na tym komponencie funkcję TrackPings z odczytanym adresem potencjalnego atakowanego. Ponadto, MTC odbiera każdą odpowiedź echo reply i wysyła ją do wszystkich dotychczas uruchomionych komponentów PTC, stosując mechanizm komunikacji typu broadcast (...send() to all component), dostępny począwszy od aktualnego wydania języka TTCN-3. Wszelkie operacje związane z porównywaniem adresu i zliczaniem są wówczas realizowane w niezależnie wykonywanych modułach testowych, co otwiera możliwość rozproszenia systemu testowego. Podczas prac nad modyfikacją przedstawionego tu testu biernego stwierdzono specyficzną cechę (a właściwie błąd) systemu OpenTTCN: operacja send() to all component nie jest obsługiwana syntaktycznie, a jej semantyczny efekt jest osiągany przy użyciu operacji ...send na porcie połączonym z wieloma innymi portami (bez stosowania klauzuli adresującej: to). Standaryzowana architektura systemu testowego przewiduje, że komponenty PTC mogą być wykonywane w sposób rozproszony, w oddzielnych węzłach sprzętowych. Jeśli założyć, że operacja wysyłania wiadomości broadcast pomiędzy komponentami systemu testowego będzie realizowana z wykorzystaniem znanych własności sieci lokalnej, uzyska się wówczas rozwiązanie skalowalne co do wydajności. Eksperyment prowadzony był z użyciem środowiska TTCN-3, które (w jego obecnej wersji) zostało zrealizowane według innej "filozofii rozproszenia" - można w nim fizycznie rozpraszać interfejsy do systemu testowanego (adaptery SA), lecz nie moduły TC. W ramach prac nad zaimplementowaniem opisanych wyżej modyfikacji ustalono eksperymentalnie. że w takim środowisku, osadzonym na popularnym sprzęcie komputerowym, uzyskuje się możliwość równoległego działania kilkuset (co najmniej rzędu dwustu) komponentów testowych. To, czy taka liczba komponentów jest wystarczająca, silnie zależy od aplikacji (tu - np. od czasu DET_TIME i szybkości transmisji w medium fizycznym, do którego dołączony jest system testowy). W ogólności, liczbę niezbędnych komponentów testowych można powiązać z liczbą wątków (kontekstów), których bieżący stan należy śledzić podczas wykonania pojedynczego testu. W literaturze szacuje się obecne skrajne oczekiwania co do tej liczby na ok. 1 miliona wątków (stanów) [30] i proponuje się metody dopuszczające pewne prawdopodobieństwo "pomyłki" przy konsultowaniu bieżącego stanu danego wątku. Te liczby wydają się (na razie) wykraczać poza standardowe możliwości systemów testowych opartych na języku TTCN..

(43) 5. PODSUMOWANIE Zaproponowano tu stosowanie TTCN-3 jako platformy dla systemów IDS m.in. z uwagi na to, że jest to technologia standaryzowana - w odróżnieniu od wielu rozwiązań proponowanych ad-hoc przez środowisko "internetowe". Jednakże, jak wskazano w [26], obecna dostępność narzędzi TTCN-3 odbiega od oczekiwań i przyzwyczajeń tego środowiska. Komercyjnie dostępne są nieliczne, kosztowne środowiska języka, w tym: OpenTTCN Tester (Finlandia), Tau Tester (Telelogic, Szwecja), TTCN-3 toolbox (Danet, Niemcy) i TTworkbench (TestingTech, Niemcy), a także firm DaVinci Communications i Strategic Test Solutions. Wysiłki zmierzające do opracowania rozwiązań opensource (np. inicjatywa T3Open [31]) nie doprowadziły dotąd, według wiedzy autora, do powstania w pełni funkcjonalnych narzędzi TTCN. Zarazem, jednym z pośrednich celów niniejszej pracy jest budowanie świadomości korzyści, jakie środowisko "internetowe" mogłoby odnieść z użycia tej technologii, co może się przyczynić do aktywizacji inicjatyw open-source. Podziękowania. Wczesne wersje testów biernych dla ataków Smurf i Neptune zostały zaprojektowane przez T. Kamińskiego, w ramach pracy dyplomowej [32] zrealizowanej pod kierunkiem autora. G.Danielewicz zweryfikował przytoczony tu tekst programu. Niniejsza praca była częściowo finansowana ze środków na naukę, w ramach grantu badawczego nr. N517 008 31/1429. SPIS LITERATURY [1]. ETSI ES 201 873. Methods of Testing and Specification; The Testing and Test Control Notation version 3; P.1-6 [2] Wenke, Readings in Intrusion Detection , www.cc.gatech.edu/~wenke/ids-readings.html (odwiedzone 10.10.2006) [3] Debar H., Dacier M., Wespi A., Towards a Taxonomy of Intrusion-Detection Systems, Computer Networks: The Int. Journal of Computer and Telecommunications Networking 31 (9) Apr. 1999 [4] Sekar R. et. al., Specification-based Anomaly Detection: a New Approach for Detecting Network Intrusions, Proc. ACM CCS'02, 2002 [5] Orset J.-M., Alcalde B., Cavalli A., An EFSM-Based Intrusion Detection System for Ad Hoc Networks, Proc. ATVA'05, 2005 [6] Sekar R., Uppuluri P., Synthesizing Fast Intrusion Prevention/Detection Systems form High-Level Specifications, Proc. USENIX'99, 1999 [7] Uppuluri P., Sekar R., Experiences with Specificationbased Intrusion Detection, Proc. RAID'2001 [8] Sekar R., Bendre M., Dhurjati D., A Fast AutomatonBased Method for Detecting Anomalous Program Behaviors, Proc. IEEE Symp. Security and Privacy, 2001 [9] Ko C., Ruschitzka M., Levitt K., Execution Monitoring of Security-critical Programs in Distributed Systems: A Specification-based Approach, Proc. IEEE Symp. Security and Privacy, 1997 [10] Eckmann S.T., Vigna G., Kemmerer R.A., STATL: An Attack Language for State-based Intrusion Detection, JCS'02, 2002. [11] Sekar R., Cai Y., Segal M., A Specification-Based Approach for Building Survivable Systems, NISSC'98 [12] Bhargavan K., Gunter C., Requirements for a Practical Network Event Recognition Language, Electronic Notes in Theoretical Computer Science 70 (4), 2002 [13] Brzeziński K.M., Kamiński T., Ewolucja języka zapisu testów TTCN: sukces czy porażka? KST'04, Bydgoszcz [14] Grabowski J., Wiles A., Willcock C., Hogrefe D., On The Design of The New Testing Language TTCN-3. Proc. Testcom'2000, 2000 [15] Grabowski J., TTCN-3 - A New Test Specification Language for Black-Box Testing of Distributed Systems, Proc. TCS'2000, 2000 [16] Hogrefe D., Koch B., Neukirchen H., Some Implications of MSC, SDL and TTCN Time Extensions for Computer-aided Test Generation, Proc. 10th SDL Forum, Copenhagen, 2001 [17] ISO/IEC 9646. Information Technology; Open Systems Interconnection; Conformance Testing Methodology and Framework; Parts 1-7 [18] Schieferdecker I., Stepien B., Rennoch A., PerfTTCN, a TTCN Language Extension for Performance Testing. Proc. 10th IWTCS, Cheju Island, Korea, 1997 [19] Dai Z., TimedTTCN-3, a Real-time Extension for TTCN3, Proc. TestCom'2002, Berlin, 2002 [20] Walter T., Grabowski J., Test Case Specification with Real-Time TTCN, Proc. 7 GI/ITG Technical Meeting on 'Formal Description Techniques for Distributed Systems', Berlin, 1997 [21] Castanet R., Laurencot P., Testing Real-Time Systems, Proc. 15th World Conference on Nondestructive Testing, Roma, 2000 [22] Wiles A., Moseley S., Randall S., The Relevance of Conformance Testing for Interoperability Testing, (version 2.0), ETSI [23] Vassiliou-Gioles T., Din G., Schieferdecker I., Execution of External Applications Using TTCN-3, Proc. TestCom' 2004 [24] Brzeziński K.M., Technologia testowania biernego w pomiarach własności sieci. W: (red.) S.Węgrzyn, B.Pochopień, T.Czachórski, Współczesne problemy sieci komputerowych - nowe technologie, WNT, Warszawa 2004, 139-146 [25] Brzeziński K.M., Towards Practical Passive Testing, Proc. PDCN'2005, Innsbruck, 2005 [26] Sabiguero A., Baire A., Floch A., Viho C., Using TTCN3 in the Internet Community: an Experiment with the RIPng Protocol, Proc. 2nd TTCN-3 User Conference, Sophia-Antipolis, 2005 [27] Deussen P.H., Din G., Schieferdecker I., A TTCN-3 Based Online Test and Validation Platform for Internet Services, Proc. ISADS'03, 2003 [28] Labib K., Vemuri V.R., Detecting And Visualizing Denial-of-Service and Network Probe Attacks Using Principal Component Analysis, Proc. SAR'04, La Londe, France, 2004 [29] RFC 792, Internet Control Message Protocol [30] Bononi F. et. al., Beyond Bloom Filters: From Approximate Membership Checks to Approximate State Machines, Proc. SIGCOMM'06, 2006 [31] www.ttcn-3.org (odwiedzone dnia 9.11.2006) [32] Kamiński T., Nowe zastosowania języka TTCN-3. Praca dyplomowa magisterska, Instytut Telekomunikacji Politechniki Warszawskiej, 2006.

(44)

WPROWADZENIE Rozważamy własności zachowania (behaviour) rozproszonych system&oacute;w reaktywnych, kt&oacute;rych przykładem są systemy telekomunikacyjne, tu zwłaszcza sieci pakietowe (w semantycznym skr&oacute;cie: Internet)

WPROWADZENIE Rozważamy własności zachowania (behaviour) rozproszonych systemów reaktywnych, których przykładem są systemy telekomunikacyjne, tu zwłaszcza sieci pakietowe (w semantycznym skrócie: Internet)