Wyższa Szkoła Informatyki i Zarządzania Wydział Informatyki

Transkrypt

1 Wyższa Szkoła Informatyki i Zarządzania Wydział Informatyki Katedra: Podstaw informatyki i technologii informatycznych Kierunek studiów: Informatyka Specjalność: Systemy informatyczne Autoreferat Pracy Dyplomowej Temat: Symulator komputerowy zapory ogniowej Dyplomant: Robert Cieślar Numer albumu: 3128 Promotor: prof. nadzw., dr n.t., dr n.f. Piotr Marecki Bielsko-Biała, 2011

2 Spis treści AUTOREFERAT WŁASNEJ PRACY DYPLOMOWEJ Wprowadzenie Sformułowanie problemu Projekt systemu Prezentacja systemu Testowanie systemu Instrukcje użytkowników Wnioski i uwagi końcowe Bibliografia...17

3 AUTOREFERAT WŁASNEJ PRACY DYPLOMOWEJ Temat pracy dyplomowej: Symulator komputerowy zapory ogniowej Dyplomant: Cieślar Robert Promotor: prof. nadzw., dr n.t., dr n.f. Piotr Marecki Rok: Wprowadzenie Geneza Od momentu popularyzacji szerokopasmowych połączeń internetowych komputery w znacznej mierze narażone są na ataki i próby nieautoryzowanego dostępu do informacji. Większość użytkowników nie zdaje sobie sprawy, że już po kilku minutach od podłączenia komputera do sieci różnego rodzaju szkodliwe oprogramowanie skanujące sieć w poszukiwaniu znanych oraz podatnych luk w zabezpieczeniach zapuka do drzwi naszego komputera. Zapora ogniowa jest jednym z niezbędnych narzędzi do walki z zagrożeniami związanymi z użytkowaniem stałego podłączenia internetowego zapewniając lepszą ochronę sieci LAN czy pojedynczej stacji roboczej. Wybierając temat pracy autor sugerował się zainteresowaniem tematyką zapór ogniowych gdyż są one nieodłącznym elementem w tworzeniu oraz zarządzaniu sieciami rozległymi. Teza pracy Komputerowy symulator zapory ogniowej jak i materiał dydaktyczny zawarty w pracy przedstawi jak ważnym mechanizmem w ochronie naszego komputera i sieci lokalnej jest zapora ogniowa. Zagrożenia pochodzące z internetu nie są tylko z zakresu szkodliwych aplikacji typu spyware, wirusów czy robaków, a ograniczenie się do aplikacji antywirusowej nie zapewnia dostatecznego poziomu zabezpieczenia na zainfekowanie się szkodliwym oprogramowaniem i nieupoważnionym dostępem do zasobów, które nie powinny być udostępnione. Cele pracy Niniejsza praca ma za zadanie przedstawienie architektury oraz mechanizmy funkcjonowania zapory ogniowej, w sposób przyswajalny dla zwykłego użytkownika 3

4 przekazać niezbędną, a zarazem cenną wiedzę na temat podstaw wymiany informacji w sieci, konfiguracji oraz wdrażania zapory sieciowej w domu czy firmie. Drugim celem pracy jest zbudowanie aplikacyjnego symulatora zapory sieciowej dzięki któremu możliwe będzie generować pakietów znanych protokołów sieciowych oraz porównywania ich z wzorcami łańcucha utworzonych reguł tabeli, co pozwoli na przeprowadzenie prostych doświadczeń oraz analizy zachowania zapory na podstawie logów systemowych. Projektowany symulator powinien posiadać następujące elementy: Możliwość definiowania reguł za pomocą takich pól informacyjnych zawierających się w ramkach jak adresów źródłowych i docelowych, portów źródłowych i docelowych oraz typów protokołów sieciowych. Generowanie dowolnej ilości ramek przychodzących Przegląd wyników symulacji w postaci wykresów oraz logów 2 Sformułowanie problemu Problemem z jakim borykają się administratorzy jest stworzenie takiej ściany ogniowej która w jak najlepszy sposób będzie chronić dostęp do sieci czy systemu przy zachowaniu jak najlepszych parametrów transmisji informacji. Należy sobie zdać sprawę z faktu, że jeżeli budowana zapora ogniowa będzie bardzo skomplikowanym układem który posiada dziesiątki reguł, a zakres sprawdzanych informacji w nagłówkach czy też danych każdej ramki będzie zbyt duży przełoży się to na czas w jakim ramki zostaną kompletnie sprawdzone, a tym samym na szybkość przekazywania tychże informacji. Głównym problemem tworzonego symulatora jest jego zaprojektowanie w taki sposób, aby odzwierciedlał on prawdziwe działanie zapory ogniowe. Oczywiste jest ze zbudowanie takiego symulatora który będzie posiadał nawet niewielką ilość możliwości którą daje nam prawdziwa zapora ogniowa jest procesem bardzo czasochłonnym dlatego też należy stworzyć uproszczony model który potrafiłby zademonstrować zasadę działania zapory na podstawie kilku podstawowych elementów. 3 Projekt systemu Model oraz założenia symulatora 4

5 Dzięki bliższemu zapoznaniu się z tworzeniem reguł oraz wykorzystywaniem zapory ogniowej w urządzeniach sieciowych które możemy spotkać na naszym rynku przyjęto następujący model tworzonego symulatora. Przyjęte zostaje tworzenie ramek których pierwowzorami są protokoły: TCP (Transmission Control Protocol), UDP (User Datagram Protocol) oraz ICMP (Internet Control Message Protocol) ze względu na ilość posiadanych pól wymienionych protokołów oraz skomplikowanie problemu rozważania wszystkich z nich przyjmuje się, że kryteria zapory będą operować tylko na pięciu polach takich jak: adres lub zakres adresów źródłowych oraz docelowych port lub zakres portów źródłowych raz docelowych tylko w przypadku obsługiwania ich przez protokół protokół sieciowych Z kolei akcjami towarzyszącymi każdej z dopasowanych ramek będzie akceptacja ramki oraz jej przepuszczenie do sieci lokalnej lub sieci internet w zależności od miejsca przeznaczenia tejże ramki. Drugą akcją będzie odrzucenie ramki oraz odnotowanie tego faktu w logach. Zostaje przyjęte, że domyślą polityką dla filtra pakietów w przypadku niedopasowania ramki do którejkolwiek reguły zapory będzie jej akceptacja. Poniższa tabela obrazuje ilość możliwości konfiguracji reguły zapory w przypadku operowania tylko na czterech polach występujących w nagłówku jednego z protokołów. Ilość ewentualnych możliwość można przedstawić jako 2 n w naszym przypadku 2 4 =16, wyobrazić sobie można ile takich możliwości konfiguracja dla tylko jednej reguły byłoby w przypadku operowania na dziesięciu polach 2 10 =1024. Adres źródłowy Adres docelowy Port źródłowy Port docelowy Rys. 1. Możliwości konfiguracji reguły operując na czterech polach 5

6 Wariant drugi - warunek zostanie spełniony tylko i tylko wtedy gdy adres źródłowy ramki jest równy adresowi lub należy do zakresu adresów podanych podczas tworzenia tejże reguły adres docelowy, port źródłowy oraz docelowy ramki nie ma w tym przypadku znaczenia może to być bowiem jakikolwiek adres lub port, oczywiście zgodny z implementacja protokołu. Wariant jedenasty warunek zostanie spełniony tylko i tylko wtedy gdy adres źródłowy, adres docelowy oraz port docelowy będzie równy lub będzie należał do zakresu adresów podanych w regule, adres źródłowy nie ma znaczenia. Wariant pierwszy ten warunek pozostał omówiony ostatni ponieważ może zastanawiać dlaczego regułą jest warunek gdzie żądne z czterech kryteriów nie posiada wartości dla których można byłoby tworzyć próbę dopasowania, otóż odpowiedz jest bardzo prosta warunek ten będzie spełniony dla każdej z ramek która dotrze do naszej zapory, jest to jak najbardziej poprawna reguła wykorzystywana w sytuacjach gdy administrator przyjmuje, że jego zapora będzie zbudowana w taki sposób w którym buduje zaporę nie do przejścia, a następnie przepuszcza tylko ten ruch który go interesuje, jednakże należy pamiętać, aby reguła ta znajdowała się zawsze na samym dole stosu reguł firewalla, w przeciwnym wypadku reszta reguł znajdujących się po niej byłaby bezużyteczna co mogłoby zakłócić, a nawet uniemożliwić całkowity przepływ. Schemat blokowy generowania ramek Rys. 2. Schemat blokowy generowania ramek 6

7 Powyższy schemat przedstawia w jaki sposób generowane są ramki potrzebne do symulowania działania zapory ogniowej. W pierwszej kolejności pobierana jest wartość liczbowa określająca ilość generowanych pakietów, następnie tworzy się zmienną pomocniczą przypisując jej wartość zero, ta zmienna będzie zwiększana o jeden po każdorazowym wygenerowaniu ramki, generowanie ramek będzie trwało tak długo aż wartość zmiennej pomocniczej j będzie równa wartości zmiennej i, w tym też momencie zakończy się generowanie ramek. W przypadku gdy j jest mniejsze lub równe i losowane są kolejno adres źródłowy, adres docelowy oraz protokół sieciowy, z kolei sprawdzany jest warunek, czy wylosowany protokół jest równy icmp, jeżeli warunek jest prawdą do tablicy dodawana jest ramka z wygenerowanymi wcześniej wartościami, w przeciwnym przypadku losowane są kolejno port źródłowy oraz docelowy i dopiero wtedy wartości dodawane są do tablicy. Porty nie są losowane dla protokołu icmp ponieważ protokół ten nie korzysta z gniazd sieciowych. Tablica zapory W momencie zakończenia operacji generowania pakietów otrzymujemy tablice dwuwymiarową często tego typu tablice nazywa się macierzami wielowymiarowymi, dzięki tego typu obiektowi możliwe jest bardzo proste odwoływanie się do dowolnej wartości w tablicy poprzez tak zwane indeksy zatem dostęp do poszczególnego elementu tablicy wygląda przykładowo tablica[numer wiersza][numer elementu]. Przykładowa tablica dwuwymiarowa dla sześciu wygenerowanych ramek przedstawiona została na poniższej ilustracji. Rys. 3. Tablica dwuwymiarowa zapory przeciwogniowej 7

8 Należy pamiętać, że w informatyce liczenie rozpoczyna się od zera dlatego też pierwszy element pierwszego wiersza posiada indeks 00. Pierwszy element tablicy to port źródłowy (AZ), drugi adres docelowy (AD), trzeci protokół (P), czwarty port źródłowy (PZ), piąty port docelowy (PD). W przypadku gdy protokółem jest icmp element czwarty oraz piąty nie posiadają wartości w związku z tym nie jest możliwe odwoływanie się w tym przypadku do indeksów trzeciego oraz czwartego. Tym samym chcąc odwołać się do protokołu piątej wygenerowanej ramki wykorzystuje się przykładowo następujący zapis var prototmp = packet[4][2] skutkiem tego jest zapisanie wartości o tych indeksach do zmiennej prototmp. Schemat symulacji Rys. 4. Schemat blokowy symulacji zapory ogniowej 8

9 Schemat zobrazowany powyżej przedstawia zasadę działania sprawdzania ramek pod kontem istniejących reguł zapory projektowanego symulatora. W pierwsze kolejności pobierane są dane potrzebne do rozpoczęcia symulacji są nimi ilość wygenerowanych ramek przypisanych do zmiennej p oraz liczba wyrażona ilością reguł uprzednio dodanych do tablicy symulatora, następnie tworzone są zmienne pomocnicze j oraz i które to wykorzystywane będą podczas tworzenia pętli logicznych w ślad za nimi zmienne accepted, rejected, mached, dla wszystkich tych zmiennych na wstępie przypisywana jest wartość zero. Po zadeklarowaniu wszystkich zmiennych zostają uruchomione pętle logiczne które to pozwolą na sprawdzanie każdej wygenerowanej uprzednio ramki pod kontem każdej reguły zapory. Ramka pierwsza z indeksem 0 czyli z wartością początkową zmiennej j zostaje poddawana próbie dopasowania dla reguły pierwszej określonej także indeksem 0 w przypadku pomyślnego dopasowania zwiększona zostaje wartość zmiennej matched o jeden, powodując sprawdzenie akcji podejmowanej dla danej reguły. W sytuacji odrzucenia ramki zmienna rejected zostaje zwiększona o jeden w razie akceptacji ramki to zmienna accepted zostaje zwiększona o jeden co z kolei odnotowane jest w dzienniku zdarzeń, powodując przerywanie pętli oraz zatrzymując dalsze sprawdzanie tejże ramki pod kontem kolejnych reguł, sytuacja ta zwiększa zmienną j o jeden przechodząc do sprawdzania następnych ramek. Oczywiste jest, że ramka niekoniecznie musi być dopasowana do pierwszej reguły w tym też przypadku następuje zwiększenie zmiennej i o jeden odpowiadającej za indeksowanie reguł zapory, następnie powtarzając czynność opisaną wcześniej. Jeżeli okaże się, że żadna z wymienionych reguł nie spełnia takich warunków by możliwe było dopasowanie do niej aktualnie sprawdzanej ramki co zostaje stwierdzone w momencie gdy wartość zmiennej i jest większa od wartości zmiennej r następuje akceptacja ramki zgodnie z założeniem, że domyślną polityką dla wszystkich ramek jest ich akceptacja w przypadku gdy reguła nie wskazuje inaczej. Sytuacja ta odnotowana jest w dzienniku zdarzeń symulatora, wartość j ponownie zwiększana jest o jeden co w następstwie powoduje sprawdzanie kolejnej ramki. Każdorazowo po zwiększeniu wartości zmiennej j zmienna i przywracana jest do wartości początkowej równej zero. Zatrzymanie symulacji następuje w momencie wyczerpania wszystkich wygenerowanych ramek czyli gdy wartość zmiennej j podczas inkrementacji jest większa od wartości zmiennej p. 9

10 4 Prezentacja systemu Graficzny interfejs użytkownika Dzięki zapoznaniu się z tematyką zapór ogniowych, wykonaniu prac projektowych oraz programistycznych opracowano aplikacje przeznaczoną do symulowania działania programowej zapory ogniowej. Przedstawiane niżej ilustracje zostały zaprezentowane w taki sposób, aby osoba czytająca ten rozdział łatwo i klarownie mogła wdrożyć się w obsługę aplikacji. Opierając się na technologi Javascript oraz dostarczonych bibliotekach środowiska Ajax Platform, stworzono bardzo przejrzysty graficzny interfejs użytkownika. Poniższy rysunek ilustruje główne okno aplikacji, jak można zaobserwować składa się ona z szeregu komponentów, które ułatwiają komunikacje między człowiekiem i aplikacją. Rys. 5. Główne okno aplikacji 10

11 Dodawanie oraz edycja reguł zapory Etapem bez którego nie byłoby możliwe uruchomienie symulacji jest zdefiniowanie reguł zapory ogniowej, pomocne w tym jest okno w którym możemy sformułować interesujące nas kryteria według których ramki będą dopasowywane do wzorca. Zdefiniowanie reguły jest bardzo proste i polega na wpisaniu odpowiednich wartości lub wybraniu ich ze specjalnego obiektu którym jest lista rozwijana. Lista rozwijana jest obiektem który umożliwia wybrać użytkownikowi element z rozwijanej listy po uprzednim kliknięciu w odpowiedni przycisk. Wprowadzane wartości w obiektach tekstowych opisanych jako adres źródłowy oraz docelowy powinny mieć zapis indywidualnego hosta, całkowity brak wartości oznaczający, że do wzorca będzie pasował jakikolwiek adres z sieci TCP/IP lub adres sieci w formie zapisu CIDR. W przypadku portów źródłowych oraz docelowych forma zapisu przypomina ten który omówiliśmy wcześniej z tym jednak wyjątkiem, że zakres portów definiujemy poprzez rozdzielenie ich znakiem myślnika. Rys. 6. Okno definiowania reguł zapory Po zdefiniowaniu oraz zaakceptowaniu nowej reguły zostaje ona dodana do tablicy zapory. Wszystkie dodane reguły można przeglądać w obiekcie zwanym tabelą. Obiekt ten pozwala na sortowanie, przewijanie, wybór elementu, zmiany rozmiaru kolumny lub przeniesienia wiersza na inną pozycję. Te i inne możliwości pozwalają 11

12 oraz pomagają w zarządzaniu stworzonymi regułami zapory. Tabela posiada siedem kolumn które odpowiadają kolejno: Action informacja jaką akcje ma podjąć zapora w momencie dopasowania informacji znajdującej się w ramce do wzorca reguły, możliwe akcje to akceptacja ramki lub jej odrzucenie Src. Address w tej kolumnie znajdują się wszystkie adresy lub zakresy adresów źródłowych dla których informacje z ramki będą dopasowywane do wzorca aktualnie sprawdzanej reguły, pole Src. Address może być puste oznaczać będzie to, że jakikolwiek adres znajdujący się w polu ramki z informacją w której zawiera się adres źródłowy będzie pasować do wzorca Dst. Address jak wyżej tylko dla adresów docelowych Protocol protokół sprawdzany podczas dopasowywania ramki do wzorca Src. Port port lub zakres portów źródłowych dopasowywanych do wzorca, pole to może nie posiadać żadnej wartości co jest równoznaczne z tym, że protokołem wybranym podczas definiowania reguły jest ICMP, który nie obsługuje portów lub w przypadku pozostałych protokołów, każdy numer portu znajdujący się w polu z informacją dla danej ramki będzie pasował do wzorca. Dst. Port jak wyżej z tym wyjątkiem, że informacją jest port docelowy Packets te pola zmieniają się dynamicznie podczas przeprowadzanej symulacji w przypadku gdy ramka zostanie dopasowana do wzorca danej reguły wartość w komórce zostaje zwiększana o jeden. Informacja ta jest bardzo przydatna podczas analizowania skuteczności reguły. Rys. 7. Tabela z regułami zapory 12

13 5 Testowanie systemu Test zostanie przeprowadzony na komputerze średniej klasy oraz przeglądarce internetowej Firefox, która to jest zalecana z powodów opisanych w podrozdziale trzecim Uwagi do testowania. Ponieważ stworzony symulator jest aplikacją webową, a ilość obliczeń znaczna testowane będzie zachowanie symulatora przy różnej ilości generowanych ramek, wyniki zostaną przeprowadzone w poniższej tabeli. Należy pamiętać, że aplikacja wykonana jest w jeżyku programowania JavaScript czego konsekwencją jest wykonywanie operacji wewnątrz silnika przeglądarki internetowej dlatego nie można pozwolić aby operacje były wykonywane dla setek tysięcy wygenerowanych ramek gdyż może to spowodować zawieszenie się przeglądarki na której został uruchomiony symulator. Ilość ramek Tab. 1. Wyniki symulacji Ramek zaakceptowanych Ramek odrzuconych Czas symulacji Brak danych Brak danych Brak danych Wyniki symulacji które zostały przedstawione w powyższej tabeli wykonywane były na komputerze z procesorem Intel(R) Core(TM)2 Duo CPU E4600 z taktowaniem 2.40GHz oraz z 2 GB pamięcią RAM, jak widać przy wygenerowanych ramek wynik jest niedostępny gdyż przeglądarka w której został uruchomiony symulator uległa zawieszeniu. Można zatem powiedzieć ze złożoność obliczeniowa jaka jest wykonywana w celu sprawdzenia takiej ilości ramek pod kątem zaledwie ośmiu reguł jest znaczna dlatego warto mieć na uwadze by podczas przeprowadzania symulacji jednorazowo nie generować więcej niż do ramek, unikniemy tym samym problemu z zawieszeniem przeglądarki. Podczas projektowania, realizacji oraz testowania systemu narzędziem które wykorzystywane było do sprawdzania poprawności działania aplikacji był Firebug dodatek do przeglądarki który umożliwia śledzenie w czasie rzeczywistym przebieg funkcjonowania aplikacji. 13

14 Rys. 8. Firebug sprawdzanie poprawności działania aplikacji Kolejnym etapem w testowaniu symulatora zapory ogniowej jest sprawdzenie poprawności wyników symulacji. Sprawdzenie poprawności polega na przebadaniu kolejno kilku lub kilkunastu wyników akcji dla ramek znajdujących się w logach sporządzonych przez symulator oraz porównaniu ich z regułami zdefiniowanymi dla zapory ogniowej. Jak widać na poniższej ilustracji symulator w tym przypadku posiada osiem reguł każda z wygenerowanych ramek zostanie sprawdzona pod kontem wzorców znajdujących się w poszczególnej z nich, wyniki dotyczące podjętej akcji dla danej ramki zapisywana jest w logach które to należy zbadać i porównać z istniejącymi regułami tego typu przeglądnięcie kilku lub kilkunastu reguł pozwoli stwierdzić czy wyniki symulacji faktycznie są prawidłowe. Rys. 9. Przykładowa konfiguracja zapory Poniższa ilustracja przedstawia wyniki kilkunastu ramek które zostały sprawdzone pod kontem wzorców znajdujących się w regułach zapory ogniowej poddane one zostaną szczegółowej analizie w celu upewnienia się, że symulator prawidłowo potrafi ocenić akcję dla poszczególnej przychodzącej ramki. 14

15 Rys. 10. Wyniki podjętych akcji dla przychodzących ramek sporządzone przez symulator Ramka pierwsza z adresem źródłowym , adresem docelowym protokołem UDP portem źródłowym oraz docelowym została odrzucona wynikiem tego są dwie pierwsze reguły pierwsza mówi, że dla adresu przyjęte mają być ramki gdzie adresem docelowym jest port 25. Zgodnie z zasadą działania symulatora ramka nie pasowała do wzorów pierwszej reguły zatem została sprawdzana pod kontem kolejnej która z kolei mówi o odrzucaniu wszystkich ramek kierowanych do tego właśnie hosta. Ramka druga z adresem docelowym oraz protokołem ICMP została odrzucona ponieważ pasowała tylko i wyłącznie do wzorca reguły ostatniej mówiącej o odrzucaniu wszystkich komunikatów ICMP których celem jest sieć /24. Ramka trzecia została zaakceptowana gdyż informacje zawarte w polach ramki nie pasowały do wzorców żadnej reguły, skutkiem czego podjęta została domyślna polityka zapory ogniowej jaką jest akceptacja wszystkich ramek. 6 Instrukcje użytkowników Z uwagi na rodzaj aplikacji tj. aplikacja internetowa wykorzystująca języki skryptowy JavaScript, PHP nie ma potrzeby instalacji jakichkolwiek dodatkowych plików na komputerze klienta, do prawidłowego jej funkcjonowania wystarczy przeglądarka internetowa, zalecaną przeglądarką internetową jest Mozilla Firefox z powodu niepoprawnego interpretowania kodu Javascript oraz środowisko Ajax Platform przez takie alternatywne przeglądarki jak Google Chrome, Internet Explorer czy Operę. Do przeprowadzenia symulacji konieczne jest wykonanie kilku kroków: podanie adresu bramy oraz maski podsieci dodanie aktywnych hostów w sieci dodanie reguł zapory ogniowej 15

16 podanie ilości ramek do wygenerowania oraz uruchomienie symulacji Analizowanie zachowania zapory możemy przeprowadzić dzięki modyfikacjom obecnych reguł zapory ogniowej, reguły możemy dodawać usuwać edytować oraz zmieniać ich pozycje w tabeli. Wszystkie zmiany możemy obserwować na wykresie kołowym który pokazuje stosunek ramek przepuszczonych oraz odrzuconych, drugi wykres liniowy przedstawia zmiany dotyczące strat czasowych oraz opóźnień w transmisji, prócz samych wykresów można przejść do zakładki z logami w celu przejrzenia wygenerowanych ramek oraz jaka została podjęta akcja dla poszczególnej z nich. 7 Wnioski i uwagi końcowe W ramach projektowania systemu została wykonana aplikacja której zasada działania polega na symulowaniu zapory ogniowej. Aplikacja została wykonana przy użyciu platformy Ajax.org oraz językowi JavaScript dzięki czemu jest całkowicie niezależny od platformy na której zostanie uruchomiona. Głównymi zaletami symulatora jest jego prostota w użytkowaniu oraz bardzo intuicyjny interfejs. Całość pracy została wykonana zgodnie z wyznaczonymi kryteriami, a informacje w niej zawarte mogą być przydatne dla każdego zainteresowanego zaporami ogniowymi. W niniejszej pracy została udowodniona teza, że nieodłącznym elementem tworzenia sieci jest zapora ogniowa, chroniąca przed atakami oraz nieautoryzowanym dostępem do informacji. Należy jednak pamiętać, że nie jest możliwe stworzenia takiej zapory, która chroniłaby sieć w stu procentach wynika to głównie ze względów ekonomicznych takich jak spory nakład pracy przy dynamicznie zmieniającej się topologi sieci oraz nowych rozwiązaniach, opóźnienie transmisji spowodowana duża ilością reguł których skutkiem jest mniejsza przepustowość łącza czy możliwości spreparowania ramki przez hakera tak, że mimo zapory ramka przedostanie się do sieci chronionej. W obecnym stanie aplikacja może z całą pewnością służyć jako pomoc naukowa w szkołach lub dla użytku osobistego. Ze względu na możliwość analizowania wyników oraz bardzo przybliżoną zasadę działania symulatora do wykorzystywanych zapór ogniowych na co dzień, każdy może nauczyć się jak tworzyć reguły aby konfiguracja była zapory była najbardziej optymalna oraz skuteczna. Dzięki prostocie budowania aplikacji za pomocą platformy Ajax.org, aplikacja bez problemu może być rozwijana 16

17 dalej, rozbudowując ją o takie elementy jak nowe kryteria porównywania informacji zawartych w ramkach, łańcuch wejściowy lub cały szereg akcji które mogą towarzyszyć regułą. 8 Bibliografia A. Publikacja 1. Robert J. Shimorski, Debra Littlejohn Shnider, Dr. Thomas W. Shnider, Wielka księga Firewalli, Helion, Gliwice 2004, ISBN: Jon Erickson, Hacking Sztuka penetracji, Helion, Gliwice 2004, ISBN: Mark Baartse, Stuart Canway, Jean-Luc David i inni, JavaScript Zaawansowane programowanie, Helion, Gliwice 2003, ISBN: Mark Sportack, Sieci Komputerowe Księga eksperta, Helion, Gliwice 2004, ISBN: B. Prace dyplomowe wykonane w WSIZ 1. Jacek Kapanowski Modelowanie i symulacja układów firewall, praca dyplomowa WSIZ, 2008, Promotor - dr n.t., dr n.f. Piotr Marecki, prof. nadzw. 2. Dawid Puszczowicz Analiza systemów firewall i ich wykorzystanie dla ochrony sieci lokalnych, praca dyplomowa WSIZ, 2006, Promotor - prof. zw. dr hab. inż. J. Korostil 3. Paweł Sieńczewski Bezpieczeństwo w sieciach , praca dyplomowa WSIZ, Promotor dr. inż. Marcin Tomana C. Witryny internetowe

18 Indeks ilustracji Rys. 1. Możliwości konfiguracji reguły operując na czterech polach...5 Rys. 2. Schemat blokowy generowania ramek...6 Rys. 3. Tablica dwuwymiarowa zapory przeciwogniowej...7 Rys. 4. Schemat blokowy symulacji zapory ogniowej...8 Rys. 5. Główne okno aplikacji...10 Rys. 6. Okno definiowania reguł zapory...11 Rys. 7. Tabela z regułami zapory...12 Rys. 8. Firebug sprawdzanie poprawności działania aplikacji...14 Rys. 9. Przykładowa konfiguracja zapory...14 Rys. 10. Wyniki podjętych akcji dla przychodzących ramek sporządzone przez symulator