Wyniki i wnioski
Na samym początku chciałem zaznaczyć, że prawdziwa możliwość zapoznania się z tymi trzema urządzeniami była wielce pouczająca zarówno w kontekście samej konfiguracji jak i sposobów ochrony zastosowanych w tych rozwiązaniach. Ogromną pomoc stanowiła także obserwacja tych urządzeń działających na prawdziwej sieci uczelnianej, przez co wiedzę nabytą po przeczytaniu różnych publikacji łączyłem z praktyczną analizą ich działania i wykorzystywania. Dlatego postaram się przedstawić pokrótce wyniki jakie udało mi się zebrać na tych urządzeniach.
Wpierw chciałbym przedstawić obciążenie oraz ogólne parametry pracy firewalla PIX, podczas normalnej pracy w systemie sieci uczelnianej. Trzeba podkreślić, że przechodzą przez niego wszystkie pakiety kierowane z i do sieci uczelnianej.
Rysunek 4.38 Ogólne parametry oraz wykorzystanie zasobów firewalla PIX działającego w sieci uczelnianej41
Na górze mamy ogólne informacje o jednostce między innymi, że posiada system w wersji 6.3(5) oraz typ wykupionej licencji, która pozwala maksymalnie na instalację trzech fizycznych interfejsów. Widać, że firewall posiada trzy możliwe interfejsy wszystkie są włączone oraz odbywa się na nich ruch. Jest to klasyczny przykład firewalla ze strefą zdemilitaryzowaną dla serwerów na interfejsie DMZ oraz interfejsem inside do połączenia z siecią wewnętrzną, oraz interfejsem outside dla sieci zewnętrznej niezaufanej. Niżej przedstawione są wykresy pokazujące między innymi, że moc procesora jest wystarczająca do zadań, które aktualnie wykonuje. Zajętość zasobów pamięci RAM jest także w normie, ponieważ już samo załadowanie systemu operacyjnego powoduje zajęcie ok. 16 MB tak że zajęcie dodatkowych 7 MB nie stanowi dużego obciążenia. Jeśli jednak planujemy rozbudowę sieci możemy zamontować większą ilość pamięci RAM, ale nie można tego stwierdzić po jednej obserwacji i należy monitorować zachowanie firewalla w różnych sytuacjach i w okresach różnego natężenia ruchu oraz skonfigurowanych funkcji.
Na kolejnych wykresach obok widzimy, że aktualnie więcej jest ustanowionych połączeń UDP (trudniej je kontrolować, ale są szybsze w realizacji) niż sesji TCP.
Następny wykres przedstawia typową sytuację ruch przychodzący do sieci jest dużo większy niż wychodzący. Obserwacja tego zachowania umożliwia dobór łącza zewnętrznego od operatora np. tutaj po dłuższej analizie można by zastosować łącze asymetryczne, które jest tańsze od opcji symetrycznej.
Na tym ekranie (poniżej) widzimy, że PIX ma zaimplementowane mechanizmy IPS może więc rozpoznawać ataki np. ping of death.
Rysunek 4.39 Okno wykresu ataków sieciowych na firewallu PIX42
Najciekawsze jednak odczyty pochodzą z IPS-a działającego w trybie inline, który jest umieszczony bliżej świata zewnętrznego niż firewall.
Przykład logu jaki można zaobserwować na IPS-ie jest przedstawiony poniżej. Analizując kolejno zapisane zagrożenia należy przede wszystkim odrzucić te, które są fałszywymi alarmami. Szczególnie na początku będą się one objawiać w bardzo dużej ilości należy je właściwie ignorować, aby nie zamazywały obrazu prawdziwych zagrożeń.
Dla nowo jeszcze całkiem nieskonfigurowanego urządzenia widać, że takimi fałszywkami będą zapewne próby skanowania portów UDP narzędziem nmap czy zamazanie segmentu TCP.
Rysunek 4.40 Zdarzenia odnotowane na IPS-ie uczelnianym43
Natomiast wysoki poziom alarmu zostaje naruszony dla sygnatury robaka ZAFI. Gdy podglądniemy szczegóły, widać to na kolejnym rysunku. Rzeczywiście ktoś z adresu 83.30.80.109 co stanowi numer należący do puli adresów usługi ADSL TP.SA z nazwą, która też jest uwidoczniona na szczegółach wysyła na serwer uczelniany pocztowy (port 25) pocztę zawierającą robaka. Najczęściej nadawca nie będzie o tym w ogóle wiedział, bo robaki same się rozsyłają i doskonale sobie z tym radzą. Dla takich pakietów można zdefiniować, aby zostały odrzucane i wpisy o odrzuconych pakietach zostały zalogowane do dzienników (jest to dobra praktyka administratorów).
Rysunek 4.41 Szczegółowy opis zdarzenia odnotowanego na IPS-ie uczelnianym44
Innym przykładem (poniżej) zdarzenia zanotowanego przez sensor jest próba przepełnienia bufora na serwerze Microsoft SQL. Może to być fałszywy alarm lub w ten sposób wykryta zostaje aktywność robaka Slammera, który atakuje takie serwery na tym porcie. Dla dokładniejszego monitoringu należy włączyć logowanie całych pakietów dla tej sygnatury i po ich analizie ocenić zagrożenie, z którym mamy do czynienia.
Rysunek 4.42 Szczegóły pakietu podejrzanego o atak na serwer MSSQL45
Oczywiście należy uaktualnić o najnowsze łatki serwer Microsoftu, który po ich instalacji już nie jest podatny na tego typu atak. Przy definiowaniu sygnatur dla których pakiety będą odrzucane trzeba je dokładnie sprawdzić, aby nie były to fałszywe alarmy i sami blokowalibyśmy usługi użytkownikom, dlatego należy te pakiety uważnie monitorować przez zapis do dziennika.
Analiza zagrożeń przedstawiona w pierwszym rozdziale pozwoliła mi poznać techniki ataku stosowane przez intruzów, oczywiście jest ich dużo więcej, ale najważniejsze z nich zostały pokrótce opisane. Jednak zabezpieczanie się przed wszystkimi możliwymi atakami nie ma praktycznego sensu i jest niepoprawne. Musimy spojrzeć na ten problem od strony zasobów, które chcemy chronić, a każdy z nich ma swoje podatności, które powinniśmy ochronić aby zamknąć ścieżkę penetracji przed intruzem.
W drugim rozdziale starałem się poznać możliwe środki ochrony tak, aby ochronić podatności danych obiektów. I jak się okazało najlepiej można tego dokonać stosując systemy bezpiecznej sieci komputerowej. Do tego celu wykorzystuje się różne sposoby zarówno sprzętowe jak i programowe oraz mieszane. Ja projektowałem system dla większej sieci, dla której głównie bezpieczeństwo zapewniają urządzenia renomowanej firmy Cisco. Nie można jednak w tym systemie zapomnieć o programowych środkach obrony jak choćby programach antywirusowych instalowanych na poszczególnych hostach wraz z regularnie uaktualnianymi bazami wirusów lub też uprawnień do folderów dla poszczególnych użytkowników. Ten cały system zbudowany na podstawie polityki bezpieczeństwa może zostać następnie wdrożony.
W trzecim rozdziale właśnie na system trzeba było spojrzeć (inżynierskim okiem) od strony technicznej jego implementacji. Dobór urządzeń ich rozmieszczenie oraz sama konfiguracja pozwoliła praktycznie spojrzeć na problem.
Z mojej obserwacji działania systemu IDS (nasłuchującego w sieci wewnętrznej na switchu bez skonfigurowanego portu typu mirror) oraz IPS (obserwującego cały ruch inline) udało mi się zauważyć wystąpienie takiego samego zagrożenia przez oba urządzenia. Wtedy zdałem sobie sprawę z istotności synchronizacji czasu urządzeń oraz ich zgodności z czasem rzeczywistym. Bez takiej synchronizacji oba zdarzenia byłyby interpretowane jako różne. Zagrożeniem był robak internetowy, który próbował się rozesłać poprzez adres rozgłoszeniowy do wszystkich hostów. Zdarzenie to zostało przeze mnie odkryte w wyniku tego, że wyeliminowałem większość fałszywych alarmów, których bardzo dużo pojawiało się na IPS-ie oraz przejrzenie logów IDS, w którym wykrytych zagrożeń było z kolei bardzo mało. Dla poprawnej bowiem analizy ruchu w przypadku IDS trzeba skonfigurować port switcha, na którym się on znajduje do mirroringu.
Innym ciekawym zdarzeniem jakie udało mi się zaobserwować tym razem na zaporze sieciowej instalowanej na komputerze to powstrzymanie rozprzestrzeniania się wirusa po lokalnej sieci. W logach tego programu ujrzałem, że wirus próbował rozesłać się do kolejnych dziesięciu adresów IP, ale jego działanie zostało zablokowane dzięki firewallowi.
Udało mi się też zaobserwować jak program antywirusowy zablokował oraz poinformował użytkownika o próbie skanowania jego portów. Gdzie rzeczywiście doszło do takiej próby podczas sprawdzania możliwości programu nmap.
Dobrze też jest spojrzeć co jakiś okres czasu na rzeczywistą pracę systemu np. na aktualnie ustanowione sesje pod kątem, czy nie ma jakiś podejrzanych połączeń, które wiemy że nie powinny być ustanowione lub działają nieprawidłowo. Często przez takie działanie można zablokować działanie trojana lub rozsyłającego się wirusa czy robaka.
Podczas wprowadzania nowej konfiguracji do systemu dobrze jest wpierw sprawdzić taką konfigurację na małej testowej sieci, czy wprowadzane kroki zapewnią działanie zgodne z naszymi oczekiwaniami. Niestety różne wersje systemów posiadają odmienne zestawy komend, co może sprawiać pewną trudność. Nowe udostępnianie opcje mogą też spowodować problemy i dlatego sieć testowa jest potrzebnym narzędziem.
Oprócz dobrego projektu, a także całego wdrożenia i konfiguracji urządzeń nie można zapomnieć o ciągłym monitorowaniu całego systemu. Musi się na to składać przeglądanie dzienników systemowych urządzeń, monitorowanie ich rzeczywistej pracy np. poprzez interfejs graficzny web. Nie można zapomnieć także o aktualizowaniu systemów działających na urządzeniach, a dla sensorów detekcji włamań bardzo ważna jest uaktualnianie bazy sygnatur. Administrator odpowiedzialny za bezpieczeństwo nie może poprzestać tylko na takich działaniach musi także bacznie czytać o najnowszych zagrożeniach pojawiających się i sposobach obrony przed nimi. Musi także zwracać uwagę na wszelkie nowe rozwiązania poprawiające sieciowe bezpieczeństwo. Ciągła edukacja administratora na temat bezpieczeństwa jest nieodłącznym elementem dobrze rozumianego systemu. Edukacja zachowywania podstawowego bezpieczeństwa sieciowego nie może też ominąć użytkowników systemu. Ważne jest zatem zapewnienie niekończącego się procesu bezpieczeństwa, który oddaje rysunek poniżej.
Rysunek 4.6 Przebieg procesu bezpieczeństwa46
Jak widać na załączonym rysunku wszystkie działania są oparte o reguły zapisane w polityce bezpieczeństwa. Pierwszym działaniem jakie należy wykonać jest spojrzenie na środowisko, w którym operuje sieć wraz z jej użytkownikami, uprawnieniami i zasobami. Wtedy można napisać politykę bezpieczeństwa. W oparciu o nią możemy przejść do zabezpieczenia sieci. Działania te polegają na wprowadzeniu właściwych rozwiązań sprzętowych jak i programowych dla zapewnienia pewnego założonego poziomu bezpieczeństwa. Następnie po uruchomieniu takiego systemu należy bacznie zwracać uwagę na jego wpływ na działanie całej sieci, szczególnie w pierwszym momencie wdrożenia, co sprowadza się do czynności monitorowania. Zauważone nieprawidłowości należy poprawić wpierw testując te rozwiązania najlepiej na stworzonej małej sieci testowej. Jeżeli będą one poprawne to można je zaaplikować sieci, co spowoduje lepsze jej działanie i zwiększenie jej bezpieczeństwa. Można znów przyjrzeć się jak wprowadzona zmiana wpłynęła na całe bezpieczeństwo systemu i w miarę możliwości znów poprawić bezpieczeństwo, a przede wszystkim ciągle monitorować działanie systemu.
Dobrym przykładem na stosowanie tego schematu ma sytuacja ataku np. przez robaka. Administrator śledzi logi systemowe i zauważa podejrzane wpisy o robaku. Następnie próbuje się dowiedzieć jak można przetestować jego obecność w systemie oraz jak przed nim się zabezpieczyć. Próbuje więc wykryć robaka poprzez testy, a następnie zastosowuje poprawki dla zagrożonych i zaatakowanych hostów. Gdy uda mu się wyleczyć zakażone hosty oraz zażegnać całkowicie zagrożenie znów jego praca głównie będzie polegać na monitorowaniu działania systemu.
Podsumowując od momentu gdy zostały wykorzystane słabości obiektów systemu komputerowego w postaci zagrożeń, pojawiły się skuteczne metody ochrony. Zawsze istnieje gorsza lub lepsza obrona przed każdym typem zagrożenia. Bowiem jeżeli ludzie wymyślają nowe rodzaje zagrożeń, to także oni potrafią się przed nimi zabezpieczyć.
Mamy odpowiednie narzędzia obrony przed zagrożeniami jednak jak dobrze potrafimy je zastosować zależy od naszej wiedzy i umiejętności. Poprzez zastosowanie systemów bezpiecznej sieci komputerowej wszyscy przyczyniają się do wzrostu bezpieczeństwa Internetu, który jest przecież siecią sieci. Ważne jest zatem stosowanie bezpiecznego systemu dla ochrony sieci komputerowej odpowiedniego dla danego środowiska, bowiem nie tylko zabezpieczamy własną sieć, ale tworzymy globalny system obronny Internetu.
Bezpieczeństwo sieci zaczyna być temat numer jeden w „globalnej pajęczynie” zwłaszcza tam gdzie sieci są już wykorzystywane od dłuższego czasu, moja praca inżynierska jest tylko kawałkiem góry lodowej na ten temat mimo iż liczy dość pokaźną ilość stron.
komentarze
Copyright © 2008-2010 EPrace oraz autorzy prac.