Bezpieczeństwo w systemach komputerowych

Wstęp

Niniejsza prezentacja dotyczy bezpieczeństwa w systemach komputerowych i powstała na potrzeby przedmiotu Systemy Operacyjne wykładanego na III roku Informatyki Uniwersytetu Warszawskiego. Autorami prezentacji są Łukasz Pejas, Piotr Turski i Rafał Wawrzyńczyk.

Prezentacja problemu

Bezpieczeństwo w systemach komputerowych jest tematem tak bogatym, że nie sposób choćby skrótowo przedstawić wszystkich jego aspektów w ramach jednej prezentacji. Obejmuje ono bowiem takie dziedziny jak:

• ludzie (pracownicy, obsługa, użytkownicy)
• sprzęt
• oprogramowanie
• nośniki danych
• infrastruktura (budynki, kontrola, zasilanie)
• dane (wyniki obliczeń, książki adresowe, itd.)
• komunikacja (sieć, poczta elektroniczna, itd.)

W związku z powyższym autorzy prezentacji zdecydowali się skoncentrować na kilku wybranych kwestiach. Plan prezentacji jest następujący:

• bezpieczeństwo aplikacji - luki, metody włamań
• wybrane aspekty bezpieczeństwa w sieciach
• mechanizmy obronne na granicy sieci
• mechanizmy obronne zintegrowane z systemem operacyjnym

Bezpieczeństwo aplikacji - luki, metody włamań

Istnieją setki rodzajów zagrożeń prawidłowego funkcjonowania systemów komputerowych. Należą tu m.in.

• przepełnienie bufora (buffer-overflow)
• niebezpieczne konstrukcje SQL (SQL Injection)
• wirusy
• robaki
• konie trojańskie
• bomby logiczne
• ataki DoS i DDoS

i wiele, wiele innych. Poniżej przedstawimy skrótowe omówienie wybranych rodzajów zagrożeń, a ze szczególną uwaga potraktowane zostaną przepełnienie bufora i niebezpieczne konstrukcje SQL.

Wirusy - programy posiadające zdolność do samopowielania się bez wiedzy użytkownika, dzięki czemu mogą szybko rozprzestrzeniać się w zainfekowanym systemie jak i poza nim (np. za pośrednictwem sieci internetowej). Wirus może doczepić się do kodu programu powodując jego wydłużenie lub nadpisać istniejący kod. Wirus składa się z głowy (część przejmująca sterowanie wykonaniem programu i służąca do samoreplikacji) oraz  ogona (mającego charakter opcjonalny i zawierającego kod odpowiedzialny np. za wyświetlanie jakiegoś napisu, kasowanie plików, itp.). Przykładowymi klasyfikacjami wirusów są następujące podziały:

• wirusy rezydentne - instalujące się w pamięci i rozpoczynające swoje działanie wówczas, gdy są spełnione określone warunki (np. nastaje wyznaczony dzień).
• wirusy nierezydentne - aktywowane wraz z zarażonym programem i usuwane z pamięci po wykonaniu swoich "zadań"

• wirusy dyskowe (wirusy sektora ładującego, boot sector viruses) - wirusy rezydentne, które uaktywniają się przy starcie systemu z zainfekowanego nośnika
• wirusy plikowe - wirusy dołączające się do plików wykonywalnych i aktywowane przez uruchomienie tego programu; mogą być zarówno rezydentne, jak
  i nierezydentne
• wirusy hybrydowe - atakują zarówno rekord ładujący systemu jak i pliki.      

Robaki (worms) - programy, których celem jest rozprzestrzenianie się za pośrednictwem sieci internetowej (niekoniecznie ma na celu modyfikowanie plików w systemie). Robaki propagują się np. drogą rozsyłania swoich kopii do osób zapisanych w książce adresowej danej osoby. Robak przesyłany jest w załączniku, a plik go zawierający ma często podwójne rozszerzenie (np. girl.jpg.vbs). Rozszerzenie .vbs jest ukrywane domyślnie.

Konie trojańskie - fragmenty kodu ukryte w programie i mogące wykonywać w sposób utajony zadania niemile widziane przez użytkownika (np. usuwanie plików). Konie trojańskie nie posiadają zdolności do samopowielania, a zarazić się nimi można jedynie instalując na dysku program będący nosicielem.

Bomby logiczne - fragmenty kodu zazwyczaj "uśpionego", a uruchamianego w przypadku spełnienia określonego warunku (np. uruchomienie określonego programu, nastanie wyznaczonego dnia). Bomby są często wykorzystywane do szantażu komputerowego.

Ataki DoS (Denial of Service) i DDoS (Distributed Denial of Service) - celem ataków odmowy dostępu jest zawieszenie lub ograniczenie funkcjonalności atakowanego serwera. Istnieje kilka głównych odmian ataków DoS; jedną z najczęściej stosowanych jest "zasypanie" ofiary ogromną liczbą pakietów, co powoduje znaczne spowolnienie działania wybranej maszyny lub jej całkowite zawieszenie. Wersja rozproszona stosowana jest przeciwko dużym serwisom internetowym i w znaczniej mierze utrudnia identyfikację napastników.

Przepełnienie bufora (buffer overflow) - spopularyzowane zostało artykułem "Smashing The Stack For Fun And Profit" opublikowanym w czasopiśmie Phrack w listopadzie 1996 r. Jest jedną z najczęściej stosowanych metod włamań do systemów komputerowych, ponieważ niejednokrotnie umożliwia uruchomienie dowolnego kodu z prawami roota.  

Aby osiągnąć swój cel, osoba dokonująca włamania przy pomocy przepełnienia stosu musi spełnić dwa cele cząstkowe:

• sprawić, by spreparowany przez nią kod znalazł się w przestrzeni adresowej atakowanego programu
• spowodować, by program przeszedł do tak załadowanego kodu

Pierwszy z wymienionych celów osiągnąć można dwoma sposobami: aplikując przygotowany kod jako wejście programu lub parametryzując kod już obecny w przestrzeni adresowej (np. ustawiając parametr "/bin/sh" i skacząc do kodu biblioteki libc). Cel drugi osiągany jest przez przepełnienie bufora i nadpisanie sąsiednich adresów żądaną sekwencją bajtów. Najczęściej nadpisywane są:

• rekordy aktywacji - odkładane na stosie przy każdym wywołaniu funkcji i zawierające m.in. adresy powrotu, informujące o miejscu, do którego powinien "skoczyć" program po zakończeniu wykonywania funkcji (rys. 1)

                                                               Rys. 1. Rekord aktywacji odkładany na stos.

• wskaźniki funkcji, które mogą być alokowane na stosie, stercie i w obszarze danych statycznych (static data area)
• bufory longjmp

Najbardziej powszechnym sposobem osiągnięcia wymienionych powyżej celów jest zaaplikowanie do programu spreparowanego słowa i nadpisanie rekordu aktywacji. Ujmując rzecz od strony praktycznej, fragment kodu uruchamiający shella zostaje skompilowany do postaci maszynowej i włączony do spreparowanego napisu, który przekracza rozmiar bufora i będzie argumentem funkcji. Po przekazaniu napisu do funkcji adres powrotny zostaje nadpisany wykonywalnym kodem lub wskaźnikiem do kodu uruchamiającego shell. Tak uruchomiony shell posiada uprawnienia programu, spod którego został uruchomiony (w szczególności są to uprawnienia roota).

Przykładem programu prowadzącego do przepełnienia stosu jest

void function(char *str)
{
    char buffer[16];
    strcpy(buffer,str);
}

void main()
{
    char large_string[256];
    int i;
    for( i = 0; i < 255; i++)
        large_string[i] = 'A';

    function(large_string);
}

Ilustrację graficzną przepełnienia bufora przedstawia rys. 2.

                                                         Rys. 2. Przepełnienie bufora.

Jak dotychczas brak w pełni skutecznego sposobu ochrony systemu przed atakami wykorzystującymi przepełnienie bufora. Do najczęściej wymienianych metod obrony należą:

• poprawne kodowanie - zwrócenie szczególnej uwagi na funkcje strcpy, sprintf, scanf, itd., które nie sprawdzają długości swoich argumentów. Większość z nich posiada bardziej bezpieczne odpowiedniki (strncpy, snprintf, itd.).

 Niepoprawnie:

 void func(char *str)
{
    char buffer[256];
    strcpy(buffer, str);
    return;
} 

Poprawnie:

 void func(char *str)
{
    char buffer[256];
    strncpy(buffer, str, sizeof(buffer) -1);
    buffer[sizeof(buffer) - 1] = 0;
    return;
}

Niepoprawnie:

void func(char *str)
{
    char buffer[256];
    buffer[0] = '\0';
    strcat(buffer, str);
    return;
}

Poprawnie:

void func(char *str1, *str2)
{
    char buffer[256];
    buffer[0] = '\0';
    strncpy(buffer, str1, sizeof(buffer) - 1);
    buffer[sizeof(buffer) - 1] = '\0';
    /* concatenate string, calculate amount of space we have left in buffer */
    strncat(buffer, str2, sizeof(buffer) - strlen(buffer) - 1);
    return;
} 

(na podstawie [8])

Wykaz funkcji stwarzających bezpośrednią okazję do przepełnienia bufora obejmuje: 

strcpy

strcat

sprintf

gets

scanf, sscanf, fscanf

memcpy

• specjalne debuggery, dokonujące losowych iniekcji "podejrzanych" miejsc i sprawdzające, czy może dojść do przepełnienia bufora
• blokada wykonywania kodu w segmencie stosu (dostępne są patche dla Linuxa i Solaris)
• kompilatory C z kontrolą przepełnienia bufora: Compaq C (ograniczona kontrola przy opcji -check_bounds), patch gcc autorstwa Jonesa i Kelly'ego (pełna kontrola kosztem 30-krotnego spowolnienia; kompilator zawodzi w przypadku dużych programów)
• stosowanie "bezpiecznych" języków programowania (Java, ML). Należy jednak mieć na uwadze, że większość kodu systemów operacyjnych została napisana w C; podobnie rzecz się ma z wirtualną maszyną Javy (jest programem C).
• StackGuard - jedna z metod tzw. code pointer integrity checking, czyli innego niż kontrola przepełnienia bufora podejścia do zapobiegania buffer-overflows. Istotą tej grupy metod jest wykrycie faktu nadpisania wskaźnika (adresu powrotu) zanim program zdąży się do niego odwołać.

Sam StackGuard jest patchem gcc umieszczającym specjalne słowo (tzw. canary) na stosie tuż po adresie powrotnym. Nadpisanie adresu powrotu (a więc i nadpisanie canary) zostanie wykryta zanim program odwoła się do zmienionego adresu (rys. 3).

                                                            Rys. 3. StackGuard

Canary może być słowem losowym (wybieranym z każdym uruchomieniem programu) albo zawierać terminatory, tj. symbole przerywające działanie funkcji kopiujących C: 0 (null), CR, LF, -1 (EOF). Daje to gwarancję, że osoba dokonująca próby przepełnienia bufora nie będzie w stanie przekazać canary w spreparowanym przez siebie słowie.

Testy wykazują, że najbardziej efektywną kombinacją jest stosowanie StackGuard wraz z blokadą wykonywania kodu w segmencie stosu.

Modyfikacją idei StackGuard jest PointGuard, umieszczający canary przy wszystkich wskaźnikach funkcji.

SQL Injection - metoda ataku baz danych wykorzystująca luki w aplikacjach SQL i pozwalająca na ominięcie firewalla chroniącego bazę. Ogólnie rzecz biorąc, polega na podaniu aplikacji sieciowej takich parametrów, które przekażą do bazy "wrogie" zapytania SQL i zwrócą ich wyniki. Celem ataku może być kradzież danych lub uzyskanie dostępu do hostów organizacji za pośrednictwem serwera bazy danych. Aby atak mógł dojść do skutku, w aplikacji będącej jego przedmiotem musi być używany dynamiczny SQL.

Lista najczęściej wykorzystywanych metod przeprowadzenia SQL Injection obejmuje:

• dodanie do zapytania UNION, po którym następuje "wrogie" zapytanie
• wykorzystanie podzapytań
• "skrócenie" instrukcji SQL  w taki sposób, by zwracała ona dane dotyczące większej liczby rekordów, niż instrukcja pierwotna
• wykorzystanie składowanych pakietów i procedur (wśród nich znajdują się często takie, które odpowiadają za odczyt i zapis w plikach)
• wykorzystanie DDL (Data Definition Language), o ile jest on używany w aplikacji
• wykorzystanie instrukcji INSERT, UPDATE lub DELETE
• wykorzystanie powiązań między bazami danych - jeżeli zaatakowana baza zawiera połączenia (links) z inną bazą, to możliwe jest dokonanie ataku na bazę danych, do której nie ma bezpośredniego dostępu przez Internet

Załóżmy (przykład na podstawie [2]), że w bazie danych składowana jest procedura get_cust(surname in varchar2) podająca numer pracownika o nazwisku surname:

create or replace procedure get_cust (lv_surname in varchar2)
is

        type cv_typ is ref cursor;
        cv cv_typ;
        lv_phone        customers.customer_phone%type;
        lv_stmt         varchar2(32767):='select customer_phone '||
                                        'from customers '||
                                       'where customer_surname='''||
                                        lv_surname||'''';

begin
        dbms_output.put_line('debug:'||lv_stmt);
        open cv for lv_stmt;
        loop
                fetch cv into lv_phone;
                exit when cv%notfound;
                dbms_output.put_line('::'||lv_phone);
        end loop;
        close cv;
end get_cust;
/

 (na podstawie [2])

Możliwymi sposobami dokonania ataku SQL Injection są w tej sytuacji np. 

• wykorzystanie UNION (dołączone zapytanie przekazuje osobie dokonującej ataku nazwy wszystkich użytkowników):

SQL> exec get_cust('x'' union select username from all_users where ''x''=''x');
debug:select customer_phone from customers where customer_surname='x' union
select username from all_users where 'x'='x'
::AURORA$JIS$UTILITY$
::AURORA$ORB$UNAUTHENTICATED
::CTXSYS
::DBSNMP
::MDSYS
::ORDPLUGINS
::ORDSYS
::OSE$HTTP$ADMIN
::OUTLN
::SYS
::SYSTEM
::TRACESVR

• skrócenie instrukcji pierwotnej drogą dołączenia tożsamości do klauzuli WHERE:

SQL> exec get_cust('x'' or ''x''=''x');
debug:select customer_phone from customers where customer_surname='x' or 'x'='x'
::999444888
::999555888
::999777888

Obrona przed atakami SQL Injection obejmuje w głównej mierze

• kontrolę kodu aplikacji wykorzystywanych do obsługi bazy danych
• przestrzeganie zasady najmniejszego uprzywilejowania (principle of least privilege) na etapie projektowania i wdrażania bazy danych  - nikt, włącznie z potencjalnym napastnikiem, nie może "zobaczyć" w bazie więcej, niż powinien

Wybrane aspekty bezpieczeństwa w sieciach

Sniffing
Sniffing jest jedną z najbardziej rozpowszechnionych metod przechwytywania danych przesyłanych przez sieć. Polega na przejmowaniu pakietów sieciowych, które często są niezaszyfrowane (telnet, ftp, poczta elektroniczna), a mogą zawierać interesujące dla napastnika informacje (login, hasło, adresy IP, itp.). Sniffery wykorzystywane są nie tylko przez hackerów, ale i przez agencje wywiadowcze, instytucje zajmujące się pomiarem ruchu w sieci, administratorów sieci, itp. Zainstalowanie sniffera wymaga praw administratora sieci.

                                                                    Rys. 4. Sniffer

Idea sniffingu opiera się na fakcie, że w sieci nie posiadającej switcha pakiety rozsyłane są do wszystkich maszyn. W zwykłych warunkach komputer ignoruje wiadomości nie przeznaczone dla niego, jednak zmiana ustawień karty sieciowej (na tzw. promiscuous mode) może sprawić, że komputer akceptuje wszystkie pakiety. Zamontowany sniffer może dodatkowo usuwać z przechwytywanych danych warstwy właściwe dla użytego protokołu i dostarczać same istotne informacje. Poniżej przedstawiono przykład przechwyconego pakietu sieciowego (żądanie klienta wysłane do serwera); po prawej stronie treść informacji zdekodowana do ASCII.

    21:06:30.786814 0:1:3:e5:46:6b 0:4:5a:d1:46:ad 0800 650: 192.168.1.3.32946 >
    66.38.151.10.80: P [tcp sum ok] 1:585(584) ack 336 win 64080 <nop,nop,timestamp 608776
    899338> (DF) (ttl 64, id 7468, len 636)
    0x0000 4500 027c 1d2c 4000 4006 8074 c0a8 0103        E..|.,@.@..t....
    0x0010 4226 970a 80b2 0050 54ac b070 78ef d6c3        B&.....PT..px...
    0x0020 8018 fa50 c663 0000 0101 080a 0009 4a08        ...P.c........J.
    0x0030 000d b90a 4745 5420 2f63 6f72 706f 7261        ....GET./corpora
    0x0040 7465 2f69 6d61 6765 732f 6275 696c 642f         te/images/build/
    0x0050 626c 6c74 5f72 645f 312e 6769 6620 4854         bllt_rd_1.gif.HT
    0x0060 5450 2f31 2e31 0d0a 486f 7374 3a20 7777        TP/1.1..Host:.ww
    0x0070 772e 7365 6375 7269 7479 666f 6375 732e         w.securityfocus.
    0x0080 636f 6d0d 0a55 7365 722d 4167 656e 743a         com..User-Agent:
    0x0090 204d 6f7a 696c 6c61 2f35 2e30 2028 5831         .Mozilla/5.0.(X1
    0x00a0 313b 2055 3b20 4c69 6e75 7820 6936 3836         1;.U;.Linux.i686

(na podstawie [3])

Metody obrony przed sniffingiem to

• oprogramowanie typu antisniff - skanuje sieć i sprawdza, czy jakieś karty sieciowe pracują w trybie promiscuous. System sniffujacy jest zwykle obciążony (programowo filtruje ramki) i może mieć to wpływ na szybkość udzielania przez niego odpowiedzi; tryb promiscuous można wykryć dzięki niedociągnięciom w TCP/IP
• szyfrowanie pakietów (np. przy użyciu SSL). Pakiet zaszyfrowany, nawet jeśli został przechwycony, pozostaje "nieczytelny" dla osoby korzystającej ze snifffera

  21:09:04.599289 opensource-01.ee.ethz.ch.https > 192.168.1.3.32933: P [tcp sum ok]
7011:7135(124) ack 793 win 10052 (DF) (ttl 237,       id 65192, len 164)
0x0000 4500 00a4 fea8 4000 ed06 43e2 8184 0799        E.....@...C.....
0x0010 c0a8 0103 01bb 80a5 be10 d77f 19a2 0520        ................
0x0020 5018 2744 8303 0000 4d3a a587 805e e2bc        P.'D....M:...^..
0x0030 9a2a 8ff3 fe95 46d4 930e b2bc 74f0 a484        *....F.....t...
0x0040 fcae 33ad 6d1f 0198 6020 aee5 0c26 908e         ..3.m...`....&..
0x0050 a1b5 17b4 84b7 44bc 1b0b 434e bbae a483        ......D...CN....
0x0060 1e23 38d3 520f 687e c5e3 b62e 5225 aa2f         .#8.R.h~....R%./
0x0070 f747 1a71 669c 8fd1 55bd 511c 4988 b78a        .G.qf...U.Q.I...
0x0080 a08d 554e a3fe bb7d 36ca e66b fb8b 0392        ..UN...}6..k....
0x0090 a3f3 4cef 7b04 af5a 7a94 cb4c a1e6 e7fa        ..L.{..Zz..L....
0x00a0 9610 a5ee                                      ....

(na podstawie [3])

• stosowanie sieci ze switchem - inaczej niż w sieciach z hubem, do danego komputera trafiają tylko pakiety przeznaczone dla niego. Ten sposób obrony jest jednak łamany przy użyciu techniki zwanej arp-spoofingiem, polegającej na podszywaniu się pod inny komputer dzięki wysyłaniu pakietów o innym, niż rzeczywisty, adresie źródłowym.

• autentyfikacja serwera
• autentyfikacja klienta
• szyfrowanie połączenia
• zapewnianie integralności danych

• Czy przedział czasu dla ważności certyfikatu obejmuje aktualną datę? Jeśli nie, komunikacja zostaje zerwana.
• Czy CA, które wydało ten certyfikat jest wiarygodnym CA? klient szuka w swojej wewnętrznej bazie certyfikatu tego urzędu. Jeśli go nie znajdzie, może szukać go w bazie zewnętrznej, do tego celu wykorzystuje się powszechnie katalogi LDAP. Jeśli przeglądarka uzyska w ten sposób poszukiwany certyfikat, nie ma pewności, że certyfikat jest prawdziwy - katalog mógł paść ofiarą włamania. Dlatego program sprawdza, kto podpisał certyfikat znaleziony w bazie. Jeśli nikt, to hierarchia podpisów jest naruszona, a otrzymany od serwera klucz publiczny nie może być uznany za wiarygodny i program pyta użytkownika o decyzje. Jeżeli jednak certyfikat CA został podpisany przez urząd znany przeglądarce (posiada ona jego klucz publiczny wbudowany na stałe), autentyczność klucza serwera jest potwierdzona.
• Czy klucz publiczny wydawcy certyfikatu serwera zatwierdza podpis elektroniczny tego CA (zawarty w jego certyfikacie)? Klient za pomocą klucza publicznego z trzymanej u siebie listy zaufanych CA weryfikuje podpis elektroniczny dołączony do certyfikatu serwera (lub sprawdzanego CA). Wszelka rozbieżność powoduje zerwanie połączenia.
• Czy nazwa domeny na certyfikacie serwera zgadza się z domeną samego serwera? Nie jest to technicznie częścią protokołu SSL ale zapobiega niebezpieczeństwu Man-in-the-Middle - programowi, który umiejscawia się pomiędzy serwerem i klientem , generuje odrębny zestaw kluczy dla każdego z nich i pośredniczy w komunikacji, dając złudzenie obu stronom, że komunikują się bezpośrednio ze sobą.

• Czy klucz publiczny klienta potwierdza jego podpis elektroniczny? Serwer sprawdza zgodność podpisu klienta z kluczem publicznym w jego certyfikacie.
• Dalszy ciąg weryfikacji odbywa się według schematu dla autentyfikacji serwera.
• Czy certyfikat klienta znajduje się w serwerze LDAP? Jest to opcjonalny krok pozwalający na dodatkową weryfikację okresu ważności certyfikatu klienta, ponieważ niektóre serwery mogą samodzielnie określać te przedziały ważności dla swoich klientów.
• Czy dany klient ma prawo dostępu do żądanych zasobów? Ostatni krok weryfikacji polega na sprawdzeniu praw dostępu tego klienta w ACL (access control lists) i ustala połączenie według określonych praw.

• Klient wysyła serwerowi numer swojej wersji SSL, listę obsługiwanych algorytmów szyfrujących i kompresujących, pewne dane losowe.
• Serwer przesyła klientowi numer swojej wersji SSL, listę obsługiwanych algorytmów szyfrujących i kompresujących. Serwer przesyła również swój certyfikat i - jeśli klient żąda zasobu, który wymaga uwierzytelnienia odbiorcy - również zapytanie o certyfikat klienta.
• Klient używa informacji przesłanej przez serwer do uwierzytelnienia serwera. Jeśli serwer nie może zostać uwierzytelniony, komunikacja zostaje zerwana.
• Klient szyfruje za pomocą klucza publicznego serwera pewne wstępne dane (premaster secret) i przesyła je do serwera. Jeśli serwer żądał uwierzytelnienia klienta, klient wysyła swój certyfikat razem z podpisem elektronicznym (czyli z losowymi danymi unikatowymi dla tej sesji, znanymi obu stronom komunikacji, zaszyfrowanymi kluczem prywatnym klienta).
• Jeśli serwer żądał uwierzytelnienia klienta, sprawdza przysłane przez klienta dane, jeśli klient nie może zostać uwierzytelniony, komunikacja zostaje zerwana. Jeśli sesja trwa dalej, serwer używa swojego klucza prywatnego do rozkodowania danych przesłanych przez klienta (premaster secret), a następnie wykonuje szereg kroków w celu wygenerowania tzw. master secret. Te same kroki wykonuje równocześnie klient.
• Master secret jest używany przez serwer i klienta do wygenerowania kluczy sesji - symetrycznych kluczy do szyfrowania i rozszyfrowywania danych i do zapewnienia ich integralności (wykrywania cudzej ingerencji w treść przesyłanych komunikatów).
• Klient przesyła serwerowi komunikat o gotowości swojego klucza i oddzielny, zaszyfrowany komunikat, że etap "handhake" po stronie klienta zakończył się.
• Serwer przesyła klientowi komunikat o gotowości swojego klucza i oddzielny, zaszyfrowany komunikat, że etap "handshake" po stronie serwera zakończył się.
• Etap "handshake" zakończył się, teraz klient i serwer używają wygenerowanego klucza do przesyłania zaszyfrowanych informacji między sobą.

Mechanizmy obronne na granicy sieci

• analiza aktywności systemu i użytkowników
• wykrywanie zbyt dużych przeciążeń
• analiza plików dziennika
• rozpoznawanie standardowych działań włamywacza
• natychmiastowa reakcja na wykryte zagrożenia
• tworzenie i uruchamianie pułapek systemowych
• ocena integralności poszczególnych części systemu wraz z danymi

• Systemy oparte na zbiorze zasad - wykorzystują one bazy danych znanych ataków i ich sygnatur. Kiedy pakiety przychodzące spełnią określone kryterium lub zasadę, oznaczane są jako usiłowanie włamania. Wadą tych systemów jest fakt, że muszą zawsze korzystać z jak najbardziej aktualnych baz danych, a także to, że jeśli atak określono zbyt precyzyjnie - to podobne, ale nie identyczne włamanie nie zostanie rozpoznane.
• Systemy adaptacyjne - tutaj wykorzystane są bardziej zaawansowane techniki, w tym nawet sztuczna inteligencja. Rozpoznawane są nie tylko istniejące ataki na podstawie sygnatur - system taki potrafi także uczyć się nowych ataków. Ich główną wadą jest cena, skomplikowana obsługa i konieczność posiadania dużej wiedzy z zakresu matematyki oraz statystyki.

• Host IDS (HIDS). Rozwiązania te opierają się na modułach agentów rezydujących na wszystkich monitorowanych hostach. Moduły te analizują logi zdarzeń, kluczowe pliki systemu i inne sprawdzalne zasoby, poszukując nieautoryzowanych zmian lub podejrzanej aktywności. Wszystko, co odbiega od normy, powoduje automatyczne generowanie alarmów lub uaktywnienie pułapek. Monitorowane są m.in. próby logowania do systemu i odnotowywane używanie niewłaściwego hasła - jeżeli próby takie powtarzają się wielokrotnie w krótkich odstępach, można założyć, że ktoś próbuje dostać się do systemu nielegalnie. Innym sposobem jest monitorowanie stanu plików systemowych i aplikacyjnych. Wykonuje się to metodą "fotografii stanów", rejestrując na początku stany istotnych plików. Jeżeli napastnikowi (lub niektórym postaciom konia trojańskiego) uda się uzyskać dostęp do systemu i wykonać zmiany, zostanie to zauważone (na ogół jednak nie w czasie rzeczywistym). Współczesne systemy potrafią monitorować i przechwytywać odwołania do jądra systemu operacyjnego lub API.

               Serwer www + system Host IDS
              /
             /
            /
    Wezeł(router+firewall)--- Serwer SQL + system Host IDS
            \
             \
              \
               Serwer poczty + system Host IDS

• Network IDS (NIDS). Rozwiązania te monitorują ruch sieciowy w czasie rzeczywistym, sprawdzając szczegółowo pakiety zanim osiągną one miejsce przeznaczenia. W swoim działaniu opierają się na porównywaniu pakietów z wzorcami (sygnaturami) ataków (attack signatures), przechowywanymi w bazie danych anomalii w ich wykonywaniu. Bazy danych sygnatur uaktualnianie są przez dostawców pakietów IDS w miarę pojawiania się nowych form ataków. Po wykryciu podejrzanej aktywności monitor sieciowy może zaalarmować obsługę sieci, a także zamknąć natychmiast podejrzane połączenie. Wiele tego typów rozwiązań jest integrowanych z zaporami ogniowymi w celu ustalenia dla nich nowych reguł blokowania ruchu, umożliwiających zatrzymania atakującego już na zaporze ogniowej przy próbie kolejnego ataku. Rozwiązania oparte na metodzie sieciowej funkcjonują w tzw. trybie rozrzutnym (promiscous mode), polegającym na przeglądaniu każdego pakietu w kontrolowanym segmencie sieci, niezależnie od adresu przeznaczenia pakietu. Z uwagi na duże obciążenie, jakie niesie ze sobą przeglądanie każdego pakietu, rozwiązania te wymagają zazwyczaj dedykowanego hosta (specjalnie do tego przeznaczonego).

               Serwer www
              /
             /
            /
    Wezeł(router+firewall+network IDS)--- Serwer SQL
            \
             \
              \
               Serwer poczty

• Network Node IDS (NNIDS). Jest to stosunkowo nowy typ hybrydowego agenta IDS, wolny od niektórych ograniczeń sieciowych IDS. Agent taki pracuje w sposób podobny do sieciowych IDS - pakiety przechwytywane w sieci są porównywane z sygnaturami ataków z bazy danych - interesuje się jednak tylko pakietami adresowanymi do węzła (ang. node), na którym rezyduje (stąd nazwa IDS węzła sieci, czasami też Stack-based IDS). Systemy takie są niekiedy określone jako "hostowe", jednak termin ten dotyczy systemów skupiających się na monitorowaniu plików logu i analizie zachowań, natomiast sieciowe i węzłowe IDS skupiają się na analizie ruchu TCP - z tą jedynie różnicą, że NIDS pracuje w trybie "rozrzutnym", podczas gdy NNIDS skupiają się na wybranych pakietach sieci. Fakt, że systemy NNIDS nie zajmują się analizą wszystkich pakietów krążących w sieci, powoduje, iż pracują one znacznie szybciej i wydajniej, co pozwala na instalowanie ich na istniejących serwerach bez obawy ich przeciążenia. W tym przypadku trzeba zainstalować cały szereg agentów - jeden na każdym chronionym serwerze - a każdy z nich musi przekazywać raporty do centralnej konsoli lub serwera logów.

• Dopasowywanie wzorców - najprostsza metoda, w której pojedyncze pakiety porównywane są z listą reguł. Jeśli któryś z warunków zostanie spełniony, uruchamiany jest alarm. Na tej zasadzie działają listy dostępu.
• Kontekstowe dopasowywanie wzorców - program bierze pod uwagę kontekst każdego pakietu. System NIDS stara się śledzić połączenia, dokonywać łączenia fragmentowanych pakietów, aby móc wychwycić większą grupę ataków oraz odfiltrować fałszywe.
• Dekodowanie protokołów wyższych warstw - NIDS dekoduje m.in. protokoły FTP, HTTP w celu analizy ich zawartości i wychwycenia specyficznych dla nich ataków. Metoda ta używana jest przez urządzenia Cisco wyposażone w moduł Content Based Access Lists.
• Analiza heurystyczna - sygnatury tego typu wykorzystują algorytmy do identyfikacji niepożądanego działania. Algorytmy te są zwykle statystyczną oceną normalnego ruchu sieciowego. Przykładem sygnatury heurystycznej jest algorytm określający, kiedy następuje skanowanie portów - będzie to przekroczona liczba połączeń z jednego adresu na kilka portów w niedługim czasie. Konkretne wartości dobierane są na podstawie statystyki.
• Analiza anomalii - sygnatury anomalii starają się wykrywać ruch sieciowy, który odbiega od normy. Największy problem stanowi określenie stanu uważanego za normalny. Niektóre systemy zawierają moduły uczące się, inne mają tą wiedzę zakodowaną na stałe. Przeprowadzanie analizy anomalii jest trudne, więc systemy stosują ją tylko w ograniczonym zakresie.

• Adres źródłowy
• Protokół
• Numer portu
• Zawartość (rzadziej)

• statyczne filtrowanie pakietów
  Zestaw reguł jest niezmienny. Określane są dozwolone adresy źródłowe i docelowe, porty i ich kombinacje.
  Największą wadą tego typu rozwiązań jest to, że (w zależności od ustawień) albo uniemożliwiają działania pewnym aplikacjom albo nie są bezpieczne.
• dynamiczne filtrowanie pakietów
  Rozwiązuje poprzedni problem. Zestaw reguł zmienia się w trakcie przepływu pakietów. Pozwala to np. przyjąć odpowiedz do portu/z adresu który w innych przypadkach jest zabroniony.
  

• domyślne przepuszczanie
  Polega na takim zdefiniowaniu warunków, aby spowodować blokowanie danych. Jeśli przychodzący pakiet nie będzie spełniał tych warunków zostanie on przepuszczony. Zaletą takiego podejścia do konfiguracji jest łatwość jej utworzenia, wadą natomiast jest to, że sieć pozostaje otwarta na większość usług i hostów (na ruch sieciowy, którego nie zablokowano).
• domyślne blokowanie
  Każdy przychodzący pakiet będzie blokowany, dopóki nie spełni warunków, które pozwolą mu przejść przez zaporę. Jest to o wiele trudniejszy sposób konfiguracji, ponieważ wymaga dokładnej wiedzy o sposobie działania protokołu TCP/IP.

• Apliction Level - Proxy
  Proxy tego typu zna protokół aplikacji dla której świadczy usługę, rozumie i interpretuje komendy w protokole aplikacji. W momencie kiedy użytkownik inicjalizuje połączenie z Proxy, wówczas Proxy dokonuje otwarcia nowego połączenia (innej sesji), czyli każda sesja posiada drugą automatycznie generowaną.
• Circut Level - Proxy
  Tworzy połączenie pomiędzy aplikacją, a serwerem bez znajomości protokołu aplikacji. Zapytanie wędruje do serwera proxy. Serwer proxy przekazuje zapytanie do Internetu po tym jak dokona zmiany IP, zewnętrzni użytkownicy widzą zatem jedynie adres IP serwera proxy. Odpowiedź jest odbierana przez proxy i przesyłana z powrotem do klienta. Dzięki temu zewnętrzni użytkownicy nie są w stanie uzyskać dostępu do wewnętrznego systemu.

• firewalle aplikacyjne (application gateway)
  Umożliwiają kontrolowany dostęp do określonych usług (takich jak ftp, telnet, www) wewnątrz chronionej podsieci poprzez odpowiedni demon pośredniczący (proxy serwer). Dla usług nie mających swojego demona ruch jest zazwyczaj całkowicie blokowany.
• firewalle połączeniowe(circuit gateway)
  Zestawiają połączenia TCP pomiędzy komputerami z sieci wewnętrznej a Internetem, korzystając z określonych zasad. (przyporządkowują pakiety do istniejących połączeń TCP i dzięki temu mogą kontrolować całą transmisję) Zaawansowane systemy potrafią także kojarzyć pakiety protokołu UDP, który w rzeczywistości kontroli połączeń nie posiada. W żadnym z powyższych przypadków firewalle połączeniowe nie kontrolują jednak samej zawartości pakietów.
• firewalle filtrujące(packet filtering gateway)
  Segreguje pakiety IP, TCP, ICMP, itp. przechodzące przez host według określonych reguł. Przeważnie reguły te opierają się na testowaniu adresu źródłowego i docelowego oraz portu pojedynczego pakietu.

• idea ,,czarnej skrzynki''
  Są to firewalle projektowane głównie przez komercyjne firmy. To zwykle urządzenia, których sposób działania nie jest bliżej znany, posiadają interfejs użytkownika i inne ułatwienia w ich sterowaniu, jednak nigdy nie możemy być pewni że nie istnieją w nich jakieś luki i nieudokumentowane obejścia.
• idea ,,kryształowej skrzynki''
  Przy koncepcji ,,kryształowej skrzynki'' zasady filtrowania pakietów są ogólno dostępne, ponieważ udostępniony jest kod źródłowy wraz z kompletną dokumentacją. Pozwala to na dokładne sprawdzenie całego kodu i wprowadzenie ewentualnych poprawek. Ma to ogromne znaczenie w przypadku systemów, gdzie dostępny jest kod źródłowy całego systemu operacyjnego, a co za tym idzie możemy dostosować konfigurację firewalla do ewentualnych niedociągnięć w samym kodzie systemu. Ten typ zdobywa sobie coraz więcej zwolenników.

• ograniczają dostęp do sieci z Internetu
• wymagają częstych uaktualnień, gdyż nowe typy klientów sieciowych i serwerów przybywają prawie codziennie
• uniemożliwiają bądź utrudniają zdalne zarządzanie siecią
• mało wydajne serwery pośredniczące zmniejszają wydajność sieci

Mechanizmy obronne zintegrowane z systemem operacyjnym

• wprowadzenie i wykonanie dowolnego kodu
• wykonanie isniejącego kodu w innej kolejności niż go opracowano
• wykonanie istniejącego kodu w prawidłowej kolejności, ale ze zmienionymi danymi

• zastąpić kod znajdujący się w pamięci innym kodem
• zastąpić dane znajdujące się w pamięci i wykonać je tak, jakby były oryginalnym kodem
• załadować nowy kod do pamięci i wykonać go

• w chwili wykrycia potencjalnie niebezpiecznej funkcji dołącza "minę-pułapkę" do stosu (ponieważ niestety mechanizm detekcji nie jest jeszcze niezawodny)
• zmienia kolejność lokalnych zmiennych w taki sposób, aby podejrzane zmienne znalazły się obok "miny-pułapki", zwiększając w ten sposób prawdopodobieństwo wykrycia błędu

• Hardened Gentoo- projekt realizowany w ramach popularnej ostatnio dystrybucji Linux-a celem projektu jest stworzenie stabilnego systemu o wysokim poziomie bezpieczeństwa, w skład projektu wchodzą między innymi: SELinux, PaX/Gr-security, RSBAC, protokoły kryptograficzne, działające elementy włączane będą do głównej lini dystrybucji - Gentoo
• Adamantix - dystrybucja rozwinięta z projektu Trusted Debian mającego na celu poprawienie bezpieczeństwa zintegrowanego z systemem w dystrybucji Debian, teraz jako samodzielny projekt; w skład projektu wchodzą: PaX, SSP, RSBAC; najwyższa dbałość o bezpieczeństwo z wymienionych tu systemów, część ogólnie dostępnych funkcjonalność Linuxa uważana za niedostatecznie przetestowane - nie są włączone do tej dystrybucji.
• OpenBSD - system z ogólnie pojętej rodziny Unix-ów, od początku główny nacisk położony na integrację bezpieczeństwa z systemem, zaletą jest daleko bardziej posunięta integracja bezpieczeństwa, wadą zaś nie dostateczne wspieranie nowych rozwiązań
• Windows - nie można obejrzeć źródeł systemu, więc mówienie o integracji opierać może się tylko na zapewnieniach prasowych, ACL, protokoły kryptograficzne oraz Service Pack polepszają bezpieczeńśtwo

Bibliografia

[1] http://downloads.securityfocus.com/library/discex00.pdf [buffer-overflow]
[2] http://www.securityfocus.com/infocus/1644 [SQL Injection]
[3] http://www.securityfocus.com/infocus/1549 [sniffing]
[4] http://www.republika.pl/b_s_k/bsk/index2.htm [bezpieczeństwo w systemach komputerowych]
[5] http://arch.ipsec.pl/ref/agh-5/ [bezpieczeństwo systemach komputerowych na przykładzie Linuxa]
[6] http://arch.ipsec.pl/ref/agh-3/ [administracja systemów komputerowych - bezpieczeństwo]
[7] http://www.leon.w-wa.pl/texts/security.php [bezpieczeństwo w Linuxie]
[8] http://www.securityfocus.com/popups/forums/secprog/secure-programming.shtml [bezpieczne programowanie]
[9] http://marcin.owsiany.pl/sec/buffer_overflow.txt ["Smashing The Stack For Fun And Profit" - lokalna kopia]
[10] http://marcin.owsiany.pl/security.pl.html [strona z linkami do stron poświęconych bezpieczeństwu]
[11] http://www.nsa.gov/selinux/ [SecurityEnchanced Linux]
[12] http://www.adamantix.org/[Adamantix]
[13] http://www.gentoo.org/proj/en/hardened/ [Hardened Gentoo]
[14] http://www.openbsd.org/ [OpenBSD]
[15] http://www.grsecurity.net/ [Grsecurity/PaX]
[16] http://www.rsbac.org/[Rule Set Based Access Control]
[17] http://www.kernelthread.com/publications/security/index.html [A Taste of Computer Security]
[18] http://www.hacking.pl