Bezpieczeństwo w systemach operacyjnych

Spis treści

·  Przyczyny luk w bezpieczeństwie aplikacji

 

·  Przepełnienie bufora

·        Błędy programistyczne

o       Przepełnianie bufora

Jest to często stosowana technika służąca do wykonywania dowolnego fragmentu kodu przez niepoprawnie napisany program z wyższymi uprawnieniami (najczęściej roota). Problem z przepełnianiem bufora został zauważony już w latach 60. i jest do dziś przyczyną wielu ataków. Polega ona ogólnie na nadpisaniu przez wprowadzone dane fragmentu kodu programu.

§        Niebezpieczne konstrukcje programistyczne

Poniżej przedstawiono kilka bardzo niepoprawnych konstrukcji programistycznych, których pojawienie się w programie zagraża przepełnieniem bufora(ang. buffor overflow):

1.        char napis[1000] – mając taką zmienną musimy uważać, żeby nie zapisać czegoś poza zakresem tablicy. Dotyczy to tablic stałego rozmiaru o elementach dowolnego typu, nie tylko char.

2.        strcpy, sprintf – te funkcje wcale się nie przejmują tym, że mogą skopiować dłuższy napis na krótszy, przepełniając bufor i nadpisując dane poza nim. Najlepiej ich w ogóle nie używać (np. zamiast strcpy jest funkcja strncpy, która kopiuje tylko n pierwszych bajtów napisu), lub przynajmniej sprawdzać wcześniej długość kopiowanego napisu.

3.        gets – tej funkcji w ogóle nie powinno się stosować. Czyta ona dane ze standardowego wejścia, więc trudno przewidzieć jakiego rozmiaru one mogą być. Tak jak poprzednie funkcje, nie kontroluje ona rozmiaru zapisanych (do bufora i dalej) danych.

§        Ogólna idea ataków wykorzystujących BO

Aby wykorzystać błąd w porgramie polegający na przepełnieniu bufora do wykonania swojego kodu należy:

1.        Umieścić ten kod w przestrzeni adresowej programu – ofiary,

2.        Spowodować, żeby program – ofiara skoczył do początku tego kodu.

Aby wykonać p. 1. wystarczy np. wprowadzić go jako jakieś dane wejściowe dla tego programu. Muszą one być w pamięci wystarczająco długo (do wykonania p. 2.) i nasz kod musi się cały zmieścić we wczytanych danych (nie koniecznie w miejscu, które było dla nich przeznaczone). Potrzebny nam też będzie adres, w którym ten kod się znalazł, jeśli znamy kod programu – ofiary, to możemy ten adres wyliczyć lub spróbować zgadnąć.

Aby wykonać p. 2. można zapisać do bufora większą ilość informacji niż jego rozmiar, przepełniając go i nadpisując gragment kodu programu – ofiary. Jeśli np. bufor jest zmienną lokalną w jakiejś funkcji, to po wywołaniu tej funkcji jest on odkładany na stos, więc za nim znajduje się m.in. na adres powrotu z funkcji. Jeśli zapiszemy tam adres kodu umieszczonego w jakimś buforze w p. 1., to po zakończeniu danej funkjci program skoczy w tamto miejsce i wykona nasz kod, który np. wywoła exec(‘bin/sh’), dzięki czemu dostaniemy konsolę z uprawnieniami takimi, jakie miał program – ofiara. Poniższy rysunek pokazuje zawartość stosu podaczas takiego ataku:

 

 

§        Sposoby zabezpieczania się przed tego rodzaju atakami

Jednym z oczywistych sposobów (ale nie koniecznie najłatwiejszych) jest pisanie poprawnych (bezpiecznych) programów, unikając m. in. konstrukcji z p. 1. Innym sposobem na zwiększenie bezpieczeństwa programów może być m. in.:

o        Zabronienie wykonywania kodu z sekcji ‘data’ programu, uniemożliwiając w ten sposób wykonanie kodu wprowadzonego przez atakującego do struktur danych programu – ofiary. Jednak w nowszych Windows-ach i Unix-ach zrezygnowano z tego rodzaju zabezpieczeń w celu poprawienia wydajności.

o        Sprawdzanie zakresów tablic – polega na sprawdzeniu wszystkich odczytów z i zapisów do tablicy czy odwołują się do elementów odpowiedniej tablicy (czy nie wychodzą poza zakres tej tablicy). To zabezpieczenie całkowicie eliminuje zagrożenie przepełnienia bufora, ale może znacząco obniżyć wydajność programu.




·  Niebezpieczne konstrukcje SQL (SQL injection)

§        Co to jest SQL injection

Sql injection jest techniką atakowania informacji przechowywanych w bazie danych mimo firewalla chroniącego ją. Polega ona na wprowadzeniu w odpowiednie miejsce (np. do odpowiedniego pola tekstowego na formularzu strony www) znaku ‘ oraz odpowiedniego fragmentu zapytania sql. W efekcie możemy przeczytać tajne dane znajdujące sięw tej bazie, a nieraz także je zmienić. Oczywistym warunkiem niezbędnym do przeprowadzenia takiego ataku jest występowanie dynamicznego SQL-a w aplikacji lub produkcie, który chcemy zaatakować.

§        Przykłady

Pokażę teraz typowy przykład mało profesionalnego mechanizmu służącego do logowania użytkowników na stronę www. Użytkownik musi podać swój login i hasło. W bazie danych przechowujemy tabelę Users zawierającą dane dla poszczególnych użytkowników:

…..

String sql = new String(

“SELECT * FROM Users WHERE Username=’” + request.getParameter(“username”) +

 “’ AND Password=’” +

 request.getParameter(“password”) + “’”

stmt = Conn.prepareStatement(sql)

Rs = stmt.executeQuery()

…..

Trudniej było by dostać siędo kodu źródłowego strony (), niż wykorzystać powyższy kod do zalogowania się na tą stronę. Możemy np. wprowadzić login: Bob, (lub prawie dowolny inny), oraz hasło: Aa’ OR ‘A’=‘A. Wtedy całe zapytanie będzie miało postać:

 SELECT * FROM Users WHERE Username=’Bob’ AND Password=’Aa’ OR ‘A’=‘A’

I będzie zwracało wszystkie rekordy z tabeli Users. Jeśli pierwszy rekord będzie zawierał np. dane administratora (co jest dość częste), zyskamy w ten sposób pełne uprawnienia na tej stronie.

Innym przykładem jest zastosowanie Unii. Poniższe zapytanie wygenerowane po wprowadzeniu złośliwych danych do formularza nie wymaga chyba komentarza:

 SELECT * FROM Towary WHERE NazwaProduktu=’test’ UNION select login, haslo from uzytkownik where ‘x’=‘x’

Można byłoby podać wiele podobnych przykładów niebezpiecznych zapytań sql. W kolejnym punkcie przedstawię, jak można się bronić przed takimi atakami.

§        Zabezpieczenia

Na ogół sądwa sposoby zabezpieczenia przed tego typu atakami:

1.        stosować „zasadę minimalnych uprawnień” na poziomie bazy danych, wtedy nawet jeśli ktoś spowoduje, że aplikacja prześle do serwera odpowiednio zmodyfikowane zapytanie, nie będzie mógł nic więcej zobaczyć niż pozwalają mu uprawnienia,

2.        Sprawdzać dane wprowadzane do aplikacji przez użytkownika. Jednym z najprostszych sposobów zabezpieczenia przed atakami techniką SQL-injection jest usunięcie z wprowadzanych napisów znaku ‘ albo zamienienie go na napis ‘’ .Zastosowanie tego zabezpieczenia dla wszystkich danych wprowadzanych przez użytkownika (najlepiej w funkcjach, które dalej używamy zawsze do wczytania danych od użytkownika) znacznie zmniejsza zagrożenie wystąpienia w naszej aplikacji takiego ataku. Jeżeli ten mechanizm jest używany niezależnie w wielu różnych miejscach kodu, zamiast w jednej wspólnej funkcji, pojawia się ryzyko, że ktoś zapomni go w którymś miejscu użyć. W takim przypadku dobrze jest przetestować aplikację wprowadzając np. w każde pole tekstowe (na każdym formularzu na każdej stronie) znak ‘ i sprawdzając czy coś się posypie…

 

·  Pasywny/aktywny dostęp intruzów do medium sieci

 

·  Podsłuchiwanie

 

W tym rozdziale zajmiemy się programami do monitorowania ruchu w sieci (snifery), pokażemy jego dobre i złe zastosowania, ogólny sposób działania i niektóre sposoby zabezpieczenia się przed podsłuchiwaniem.

o       Co to jest sniffer

Sniffer jest to oprogramowanie pozwalające przechwycić informacje przesyłane do i z komputera podłączonego do sieci. Są one dostępne na wiele różnych platform, w wersjach komercyjnych oraz open-source. Te najprostrze po prostu wyświetlają przechwycone dane na ekran, inne używają GUI do wyświetlania różnych statystyk i posiadają wiele opcji konfiguracyjnych.

o       Zastosowania

Sniffery mają wiele różnych zastosowań, m. in monitorowanie sieci i wyświetlanie ststystyk, wykrywanie ataków i innych niepożądanych działań w sieci, monitorowanie e-maili (np. różne agencje rządowe mogą chcieć podsłuchiwać e-maile, sms-y, żeby upewnić się, że nie ma tam słów takich jak np. bomba, terrorysta itp.), debugowanie programów sieciowych, czy nawet podobno do nauki działania sieci i protokołów przez początkujących klikaczy. Służą też nieraz jako engine do innych programów (np. IDS) Sniffery mogą jednak też być wykorzystywane przez nieuczciwych użytkowników do przechwycenia tajnych danych (np. loginy, hasła)

Istnieją jednak sposoby zabezpieczenia tych danych, więcej o nich opowiemy w p. 4.

o       Jak działa sniffer

Większość komputerów działa w sieciach LAN. Jeśli w sieci nie ma switcha, to dane (pakiety) przeznaczone dla jednego komputera są rozsyłane (broadcast) do wszystkich komputerów w danym segmencie, jednak karty sieciowe pozostałych koputerów zazwyczaj ignorują je. Sniffer jest programem, który przełącza karte sieciową komputera w tryb „rozwiązły”, pozwalający czytać wszystkie dane przesyłane w danym segmencie sieci (wymaga to (?) uprawnień roota). W nagłówkach tych pakietów są zazwyczaj informacje takie jak adres ip, mac nadawcy i odbiorcy i wiele innych informacji.

o       Jak się bronić przed podsłuchiwaniem

W p. 2. powiedziałem, że sniffery mogą być wykorzystywane do przechwycenia tajnych danych, które przesyłamy przez sieć przez osoby trzecie. Istnieje jednak kilka sposobów, żeby się przed tym zabezpieczyć:

§        Antysnifery

Są to programy skanujące sieć w poszukiwaniu kart sieciowych działających w trybie rozwiązłym umożliwiającym podsłuchiwanie.

§        Sieci ze switchem

Te inteligentne urządzenia, w przeciwieństwie do hub-ów,  nie wysyłają wszystkich informacji do każdego komputera w segmencie sieci. Istnieją jednak programy takie, jak np. dsniff, używające techniki pozwalającej podsłuchiwać także w sieci ze switchem.

§        Szyfrowanie

Chyba najlepszy sposób na zabezpieczenie danych podczas przesyłania ich przez sieć. Nawet jeżeli ktoś inny przechwyci te dane, nie będzie mógł ich odczytać. Zazwyczaj stosuje sięw tym celu odpowiednie protokoły, np. TLS czy SSL, który omówię w następnym punkcie.

o       Przykładowe programy (linki)

-          tcpdump: http://www.tcpdump.org/

-          ethereal : http://www.ethereal.com/

-          ettercap: http://ettercap.sourceforge.net/

-          dsniff: http://www.monkey.org/~dugsong/dsniff/

 

·  SSL

Ssl (Secure Sockets Layer) jest to protokół mający zapewnić bezpieczne połączenie w sieci.

Działa on pomiędzy protokołem TCP/IP a innymi protokołami, tzn. korzysta z protokołu TCP/IP, natomiast inne protokoły, np. HTTP, LDAP korzystają z niego w celu zabezpieczenia połączenia.

o       Zastosowanie

Kiedy użytkownik wpisuje w przeglądarce adres strony www, np. ‘www.jakiśbank.com.pl’, DNS i inne mechanizmy ustalają, jaki adres IP został w rzeczywistości zarządany. Mechanizm ten często nie zależy ani od użytkownika ani od administratora strony www i jest podatny na wiele ataków, więc użytkownik może zostać przekierowany np. na stronę z pornografią lub na stronę hakera, wyglądającą podobnie jak oryginalna strona, ale po podaniu hasła przesyłająca je tylko do niego. Łatwo można sobie wyobrazić skutki takiego błędu. Dlatego powstał m. in. Protokół SSL. Protokół SSL zapewnia:

§        Autoryzację

Za pomocą certyfikatów elektronicznych SSL zapewnia sprawdzenie, czy serwer z którym się połączyliśmy rzeczywiście jest tym, którego rządaliśmy. Od SSL v3.0 dostępna jest także autoryzacja klientów.

§        Prywatność

Po nawiązaniu połączenia dane są szyfrowane.

§        Integralność przesyłanych danych (sumy kontrolne)

o       Certyfikaty elektroniczne

§        Certyfikat CA

§        Certyfikat serwera

§        Certyfikat klienta (od v.3)

o       Jak działa SSL

Przed rozpoczęciem przesyłania danych następuje „uścisk dłoni” – autoryzacja klienta i serwera oraz ustalenie algorytmu i kluczy do szyfrowania danych. „Uścisk dłoni” przebieba w następujący sposób:

-          Klient wysyła do serwera m.in.: nr swojej wersji SSL, ustawienia dotyczące szyfrowania, oraz losowo wygenerowane dane,

-          Serwer zwraca mu m.in.: nr swojej wersji SSL, ustawienia dotyczące szyfrowania, losowe dane, oraz swój certyfikat. Jeśli wymagana jest autoryzacja klienta, przesyła mu także żądanie pochwalenia się swoim (klienta) certyfikatem.

-          Klient sprawdza czy dane przesłane przez serwer (m. in. Data ważności certyfikatu, podpis elektroniczny oraz CA które wystawiło certyfikat) pozwalają mu zaufać, wpp. komunikacja zostaje zerwana

-          klient generuje wstępne dane (premaster secret), szyfruje je kluczem publicznym serwera i przesyła je do niego. Jeśli serwer zarządał autoryzacji, wysyła też swój certyfikat

-          jeśli serwer wymagał autoryzacji klienta, sprawdza dane przez niego wysłane, jeśli autoryzacja się nie powiodła, komunikacja zostaje zerwana. Serwer odkodowywuje premaster secret

-          Klient oraz serwer równolegle przekształcają premaster secret w master secret, następnie wysyłają sobie nawzajem komunikat o zakończeniu generowania master secret i zarazem zakończeniu etapu „uścisku dłoni”

-          Dalsza komunikacja jest szyfrowana kluczem symetrycznym master secret.

o       Wady SSL

Należy pamiętać, że ssl służy tylko do zabezpieczenia danych podczas przesyłania, a nie na serwerze. Hakerzy mogą próbować wykraść ważny certyfikat używając np. koni trojańskich. Mogą oni również próbować wygenerować ważny certyfikat klienta, jeśli zgadną jego login (wystarczy zgadnąć nazwę użytkownika, nie jest konieczne zgadywanie hasła). Nieszczęście może być też spowodowane przez błędy ludzi: publiczne CA zazwyczaj mniej się starają sprawdzić, kim dany użytkownik jest, niż administrator strony www, np. Verisign potrafiło dać grupie hakerów certyfikaty np. administratora (imie: ‘Administrator’, nazwisko: puste), co dało mu m.in. uprawnienia administratora na serwerze Microsoftu IIS.

o       Podsumowanie

SSL jest tylko jednym z narzędzi do zapewnienia bezpieczeństwa komunikacji w sieci. Użycie SSL nie zwalnia nas z konieczności stosowania pozostałych zabezpieczeń, jednak w połączeniu z nimi (o ile one funkcjonują poprawnie), dobrze zabezpiecza połączenie między klientem a serwerem.




·  Mechanizmy obronne na granicy sieci

·  Zapory

 

Czym jest firewall?

Zapora sieciowa (firewall) jest urządzeniem zaprojektowanym do zapobiegania niepowołanemu dostępowi do sieci. Urządzeniem tym zazwyczaj jest niezależny komputer lub inny sprzętowy element sieci. Zapora stanowi jedyny punkt wejściowy do sieci lokalnej - jej zadaniem jest kwalifikacja nadchodzących z zewnątrz zgłoszeń według zadanych reguł i ich przetworzenie, co w najprostszym ujęciu sprowadza się do akceptacji, bądź odrzucenia żądania połączenia z danym serwerem usług sieciowych.

W większości przypadków kwalifikacji żądania połączenia dokonuje się bazując na adresie źródłowym pakietu. Jeśli, przykładowo, nie chcemy udostępniać usług naszego serwera użytkownikom z danej domeny, wprowadzamy odpowiednią maskę do reguł sterujących zapory i odtąd próby połączenia z naszym serwerem dla danej grupy użytkowników zakończą się komunikatem "Connection Refused" (połączenia odmówiono) lub podobnym (możliwa jest również sytuacja, gdzie połączenie jest zrywane bez prezentacji żadnego komunikatu).

Inne zadania realizowane przez zapory sieciowe

Zapory sieciowe mogą przeprowadzać analizy nadchodzących pakietów różnych protokołów. W oparciu o taką analizę, zapora sieciowa może podjąć różne działania, zatem możemy zaprogramować firewall do przeprowadzania warunkowego przetwarzania pakietów. ("Jeśli zostanie napotkany pakiet spełniający warunek A, podejmij działanie B").

Takie warunkowe struktury nazywane są regułami. Na ogół, podczas "stawiania" zapory wyposażamy ją w zestaw reguł odzwierciedlający strukturę zależności służbowych w naszej organizacji. Na przykład, załóżmy, że w firmie jest dział sprzedaży i księgowości, a strategia przedsiębiorstwa wymaga, aby tylko dział sprzedaży miał dostęp do zasobów naszego serwera. Aby wymusić realizację tej polityki, wyposażamy nasz firewall w regułę nie przyjmującą zgłoszeń połączenia otrzymywanych z działu księgowości. W takim aspekcie zapory sieciowe są tym dla sieci, czym są przywileje użytkownika dla systemu operacyjnego. Windows NT pozwala na wskazanie użytkowników mających dostęp do danego pliku lub katalogu. Jest to kontrola dostępu na poziomie systemu operacyjnego. Podobnie zapory sieciowe pozwalają na zastosowanie kontroli dostępu do zasobów naszego serwera i stacji roboczych w sieci.

Monitorowanie dostępu jest jednakże tylko częścią tego, do czego można wykorzystać nowoczesne zapory sieciowe - większość komercyjnych firewalli pozwala na kontrolę zawartości pakietów. Można to wykorzystać do odfiltrowywania niepożądanych skryptów JavaScript, VBScript i ActveX oraz plików cookies. Co więcej, mamy możliwość zdefiniowania reguł dyskryminujących poszczególne połączenia na podstawie tzw. sygnatur ataku.

Sygnatury ataków są wzorcami poleceń charakterystycznymi dla danego ataku. Przypuśćmy, że nasz intruz "telnetuje' się na port 80 i wydaje szereg istotnych z jego punktu widzenia komend. Znajšc taki proces, możemy "nauczyć" firewall rozpoznawać i blokować podobne ataki na podstawie wzorca zawartego w sygnaturze. Podobne efekty można również uzyskać analizując ruch na poziomie pakietu. Nektóre programy do zdalnego wykorzystywania luk systemowych generują charakterystyczne pakiety, które można wyodrębnić i podjąć odpowiednie działania.

Z czego składa się zapora sieciowa

Zapora sieciowa w swej istocie jest raczej koncepcją, a nie produktem. Celem istnienia zapór jest przyznanie, bądź odmowa przyznania połączenia danemu użytkownikowi do danej usługi sieciowej. W bardziej ogólnym sensie zapora sieciowa składa się z odpowiedniego oprogramowania i sprzętu. Oprogramowanie może być typu freeware, shareware lub komercyjne. Sprzęt może być jakimkolwiek urzšdzeniem, na którym pracuje dany program.

Typy zapór sieciowych

Wyróżniamy dwa podstawowe typy zapór sieciowych:

Zapory pracujące na poziomie sieci są zazwyczaj routerami z zawansowanymi możliwościami filtrowania pakietów. Administrator korzystajšcy z takiej zapory ma możliwość przyznania, bądź odmowy dostępu do swego serwem w oparciu o kilka zmiennych. Są to między innymi:

Zapory sieciowe w postaci routerów są popularne ze względu na łatwość ich zastosowania (po prostu podłącza się firewall do sieci i zaopatruje w odpowiednie reguły). Co więcej większość współczesnych routerów ma możliwość translacji/konwersji protokołów (gdzie protokół IP z zewnątrz jest tłumaczony na inne protokoły stosowane w sieci lokalnej). Dodatkową zaletą zastosowania firewalla zbudowanego w oparciu o router jest fakt, że z racji swej specyfiki urządzenie.takie jest elementem zewnętrznym z punktu widzenia naszej sieci lokalnej. Tak więc jego podłączenie do sieci nie wymaga konieczności konfiguracji dziesiątek maszyn czy usług. I wreszcie, jeśli nasza sieć jest połšczona z Internetem łączem stałym, to router i tak jest jej niezbędnym elementem. Zatem stosując firewall w oparciu o router możemy upiec dwie pieczenie na jednym ogniu. Z drugiej strony zapory sieciowe oparte na routerach maja kilka wad. Jedną z nich jest fakt, że wiele routerów jest podatnych na ataki, polegające na fałszowaniu adresu nadawcy pakietu - spoofing (aczkolwiek producenci pracują nad rozwiązaniem tego problemu). Z praktycznego punktu widzenia, istotna jest również efektywnoąć (moc obliczeniowa) routera - jeśli zadamy bardzo szczegółowe kryteria filtrowania, to w przypadku dużego natężenia ruchu przychodzącego możemy się spodziewać spadku jego wydajności. Niektóre routery nie posiadają wystarczająco szczegółowych możliwości zapisu stanu pracy. Oznacza to, że możemy potrzebować zewnętrznego oprogramowania i sprzętu do celów monitorowania pracy routera.

Zapory sieciowe realizowane w oparciu o aplikacje bramy Innym rodzajem zapory sieciowej jest firewall wykorzystujący aplikacje pośredniczšce w standardowej komunikacji typu klient-serwer. Zapora taka zwana jest również bramą proxy, bądź bramą programową (application gateway). Żądanie połączenia z daną usługą sieciowš wysłane przez zdalnego użytkownika jest obsługiwane nie bezpośrednio przez odpowiedni serwer usług, lecz podawane do niego poprzez bramę proxy. Zatem, w odróżnieniu od firewalla - filtra pakietów, nadchodzące pakiety IP nie są po przetworzeniu przesyłane do sieci lokalnej, zamiast tego brama przeprowadza swego rodzaju translację pośrednicząc pomiędzy klientem a serwerem. Zaletą stosowania bramkowania usług jest fakt zapobiegania dostaniu się pakietów IP do naszej sieci (tunelowania pakietów). Wadą jest konieczność konfiguracji odpowiedniej bramy dla każdej usługi sieciowej, w tym FTP, Telnet, HTTP, e-mail itd. Dodatkowo użytkownicy muszą wykorzystywać programy klienckie pozwalające na stosowanie bramkowania usług (w przeciwnym wypadku, użytkownicy będą musieli nauczyć się "ręcznie" obsługiwać bramę (co może być czasochłonne, uciążliwe, bądź w ogóle niemożliwe, zależnie od stopnia skomplikowania procedur). Przykładowo - w przypadku bramkowania popularnej usługi Telnet nie jest wymagana obecność po stronie użytkownika klienta świadomego istnienia bramy proxy; w takiej sytuacji jednak wymusi to na użytkowniku konieczność połšczenia się (lecz nie zalogowania) z bramš - firewallem dla danej usługi - a nie bezpośrednio z serwerem Telneta. Zastosowanie klienta wspierającego procedury bramkowania uczyni bramę transparentną z punktu widzenia użytkownika. Zapora sieciowa służy jako wejście do systemu docelowego - przechwytuje żądania połączenia i podejmuje dalsze, uprzednio zdefiniowane, kroki, np. zapytanie o jednorazowe hasło. Zachowanie użytkownika pozostaje takie samo, pod warunkiem stosowania odpowiednio zmodyfikowanych i skonfigurowanych klientów i usług.

Tłumaczenie adresów - Network Address Translation

Translacja adresów jest implementowana w większosci firewalli i jest u˙zywana wtedy, gdy nie chcemy, aby zdalny system poznał prawdziwe adresy IP w wewn˛etrznej sieci. S ˛ a trzy sposoby translacji adresów:

·  ukrywanie adresu sieciowego (ukrywanie NAT)

·  statyczna translacja adresów sieciowych (statyczne NAT)

·  translacja numerów portów (PAT)

Ukrywanie NAT polega ukryciu wszystkich wewnętrznych adresów IP za jednym adresem IP, który może być adresem IP firewalla lub zupenie innym poprawnym adresem. Największym ograniczeniem tej metody jest brak możiwosci polšczenia się z zewnštrz. Ponieważ wszystkie komputery schowane sš za jednym adresem IP, firewall nie ma mozliwosci sprawdzenia, do którego z komputerów w wewnętrznej sieci kierowane jest połšczenie. Statyczne NAT jest podobne do ukrywania NAT, z wyjatkiem tego, że każdy lokalny adres IP jest ukryty za osobnym adresem. Pozwala to firewallowi na rozpoznanie do którego komputera skierować połšczenie. Wiekszosć urzadzeń NAT pozwala na jednoczesne ukrywanie NAT i statyczne NAT. Pozwala to na przydzielenie osobnych adresów tylko tym systemom, które tego potrzebuja, ukrywajac inne. Translacja PAT jest używana przez większosć serwerów proxy. Cały ruch na zewnatrz jest tłumaczony w taki sam sposób, jak ukrywanie NAT, lecz adresy musza być ukryte za adresem firewalla. Aby umożliwić ruch przychodzacy z zewnatrz, mapuje się porty do konkretnego systemu.

Konstrukcja zapory sieciowej

Przy "stawianiu" zapory sieciowej istotne jest przeprowadzenie poniższych czynności:

Rozpoznanie topologii sieci oraz potrzeb w zakresie aplikacji i protokołów

To zagadnienie jest dużo trudniejsze niż mogłoby się wydawać, zależy ono od struktury i rozmiarów danej sieci. Jeśli administrujemy sieciš jednorodnš (co jednak zdarza się dość rzadko), zadanie jest proste - będziemy mieć do czynienia z jednym systemem operacyjnym i przypuszczalnie takim samym zestawem aplikacji obecnym na każdej ze stacji.

Większość sieci, to sieci heterogeniczne, co zmusza administratora do identyfikacji każdego systemu operacyjnego i wszystkich zestawów aplikacji używanych w sieci. To z kolei wymagać może konieczności korzystania z usług ekspertów w dziedzinie bezpieczeństwa poszczególnych aplikacji.

Analiza zależności służbowych

Ten krok może wymagać od administratora rozpoznania potrzeb i uzgodnienia działań z poszczególnymi działami firmy podłączonymi do sieci. Musimy uniknąć sytuacji, kiedy ze względu na fizyczną odległość między poszczególnymi segmentami sieci ruch wewnętrzny będzie się odbywał poprzez którąś z naszych bram programowych. Zatem przed dokonywaniem zmian w strukturze sieci należy dokładnie przeanalizować te zależności. Cały ten proces wymaga dużego taktu. Można spotkać się z użytkownikami lub menedżerami, którzy będą sprzeciwiać się zmianom (skoro od 10 lat sieć chodzi, to po co cokolwiek zmieniać?). Konieczna jest bliska współpraca z użytkownikami i uzasadnienie im konieczności przeprowadzenia zmian. Ostatnią rzeczą jaką byśmy sobie życzyli, to rzesza niezadowolonych lokalnych użytkowników - to od nich w przyszłości będzie zależeć bez pieczeństwo sieci, to nasi użytkownicy przestrzegając (lub nie) zasad korzystania z systemów będą mieli decydujący wpływ jej bezpieczeństwo. Jeśli staraliśmy się rzeczowo (i przystępnie) uzasadnić konieczność przedsięwzięcia odpowiednich środków - nie mamy się czego obawiać; jeśli zaś wprowadziliśmy drakońskie reguły korzystania z sieci bez słowa wyjaśnienia, możemy się spodziewać oporu materii ludzkiej na każdym możliwym kroku.

Zastosowanie i testowanie zapory sieciowej

Po zakupie zapory sieciowej powinniśmy przeprowadzić intensywne testy w dwóch fazach:

Pierwsza faza może być przeprowadzona w dowolnym czasie - nawet gdy użytkownicy danej sieci są nieobecni (weekend, godziny wieczornonocne, etc.).

Druga faza jest bardziej skomplikowana. Należy się spodziewać wielu problemów, a nawet przejściowego zaniku funkcjonalności sieci (trzeba być przygotowanym na reakcję zdenerwowanych użytkowników). Jest wyjątkowo mało prawdopodobne, że fazę tę przejdzie się gładko już za pierwszym razem - chyba, że sieć jest całkowicie jednorodna i mamy do czynienia z tym samym zestawem aplikacji na każdej z maszyn.

Czy zapory sieciowe sš niezawodne?

Odpowiedź brzmi - nie. Wiele serwerów, na których zastosowano zapory sieciowe, zostało pokonanych przez krakerów. Wynika to nie tyle z właściwości zapory sieciowej jako takiej, a raczej z zawodności tzw. czynnika ludzkiego. Najczęstszą przyczynš wadliwości zabezpieczeń firewalla sš administratorskie błędy w jego implementacji. Nie znaczy to, że niektóre zapory sieciowe nie mają słabych punktów. Owszem mają - aczkolwiek w większości przypadków luki te nie mają zbyt wielkiego znaczenia dla bezpieczeństwa sieci.

 

·  Systemy wykrywania/powstrzymywania intruzów (IDS/IPS)

Porownanie IDS / IPS

 

Projektowanie i implementacja zabezpieczeń

przed atakami intruzów

Zapewnienie właściwej ochrony przed zagrożeniami z sieci to obecnie podstawowe wymaganie bezpieczeństwa w systemach informatycznych. Pojawiają się coraz bardziej doskonalone techniki penetracji i włamań jak ataki hybrydowe oraz szybko rozprzestrzeniające się w sieci inteligentne robaki i Trojany. Zabezpieczenia starej generacji jak Network IDS (ang. intrusion detection system) działające na zasadach nasłuchu sieci (określane także jako Sniffer IDS), czy firewalle typu Stateful Inspection nie radzą sobie z tym zadaniem. Od systemów zabezpieczeń wymagane jest wykrywanie ataków i ich skuteczne blokowanie. Zabezpieczenia tej klasy określane są jako IPS (ang. Intrusion prevention system). Pierwszą ich implementacją były systemy Host IPS. Nie przyjęły się one jednak w powszechnym zastosowaniu, ponieważ sprawiają problemy ze stabilnością pracy chronionych serwerów i w praktyce nie blokują wielu ataków. Oprogramowanie Host IPS jest bowiem instalowane bezpośrednio na serwerach i przez to stwarza ich dodatkowe obciążenie i może powodować zakłócenia pracy. Konieczne stało się opracowanie zabezpieczeń sieciowych, które potrafią wykrywać ataki i skutecznie powstrzymywać je w czasie rzeczywistym (tzn. blokować pakiety wykonujące atak przed ich dotarciem do chronionych systemów). W ostatnich latach na rynku pojawiła się nowa generacja zabezpieczeń IPS łącząca w sobie funkcje firewall i IDS, określana jako Network IPS, In-line IDS lub Deep Packet Inspection. Przykładami tych zabezpieczeń są Check Point with Application Intelligence, ISS Proventia G, NAI McAfee IntruShield oraz NetScreen Intrusion Detection and Prevention (IDP). W dalszej części opracowania zostaną przedstawione przykłady konfiguracji i praktyczne testy zabezpieczeń z wykorzystaniem NetScreen-IDP. System ten jest pierwszym na rynku „dojrzałym” rozwiązaniem tej klasy.

Przegląd technik ataku

Intruzi stosują wiele różnych metod ataku. Można wyróżnić dwie uznawane za najgroźniejsze techniki włamań do systemów komputerowych:

– włamanie przez exploit polegające na bezpośrednim połączeniu intruza z

atakowanym systemem i wykonaniu w nim niedozwolonych działań dzięki

wykorzystaniu błędu jego aplikacji,

– włamanie przez agenta polegające na przesłaniu do systemu specjalnie

napisanego programu, który po uruchomieniu wykonuje niedozwolone działania

zaprogramowane przez intruza.

 

 

 

 

 

Rys 1) Typowy scenariusz włamania do sieci                                  

 

 

Skuteczność systemów ochrony

Atak przez exploit jest zwykle wykonywany w bardzo krótkim czasie. Jest to

jednokrotne połączenie z serwerem i uruchomienie na nim złośliwego kodu. W praktyce za

pomocą zabezpieczeń Sniffer IDS nawet zintegrowanych z systemem firewall (tzw. firewall

signaling) nie ma możliwości blokowania ataków. Jedyne skuteczne w tym zakresie środki

ochrony to Network IPS. Mimo pozornego podobieństwa Sniffer IDS zintegrowany z

firewallem zachowuje się zupełnie inaczej jak Network IPS i w rzeczywistości stwarza

większe zagrożenie niż korzyści. Różnicę tę najlepiej zrozumieć analizując popularne

scenariusze włamań do systemów informatycznych. Zasady działania obu rozwiązań

ochrony przedstawia rysunek 3. Porównanie skuteczności dedykowanego systemu Network

IPS i Sniffer IDS zintegrowanego z firewallem można łatwo przeprowadzić nawet w

warunkach prostej sieci lab.

 

Systemy IPS są w stanie skutecznie, w sposób aktywny przeciwstawiać się atakom

intruzów funkcjonując w trybie in-line (patrz rysunek 3). Zasady działania Network IPS są

podobne do systemów firewall. Ruch wchodzi do urządzenia IPS przez interfejs sieciowy

i wewnątrz jest poddawany analizie, a następnie wychodzi z urządzenia innym interfejsem.

Dzięki temu kontrola ruchu sieciowego jest łatwiejsza, pojawia się mniej jak w Sniffer IDS

fałszywych alarmów i co najważniejsze całkowicie eliminowane jest zagrożenie, że IPS

„zgubi pakiety”. Najistotniejsze jest jednak, że w trybie in-line ataki mogą być w czasie

rzeczywistym blokowane przed ich dotarciem do chronionych zasobów systemu

informatycznego. Rysunek 4 przedstawia zasady kontroli ruchu sieciowego w systemie

zabezpieczeń NetScreen-IDP. Analiza ruchu sieciowego odbywa się w oparciu o różne

techniki detekcji m.in. Stateful Signatures, Protocol Anomalies, Network Honeypot, Backdoor

Detection, Traffic Anomalies, Spoofing Detection, Layer 2 Detection i Denial of Service

Detection.

 

 

Systemy IDS(Intrusion Detection Systems)

Zadanie systemu wykrywania intruzów polega na ochronie sieci przed włamaniem. Przez włamanie rozmumiemy tu sekwencje zdarzeń zagrażającą bezpieczeństwu sieci. Podstawą wykrywania włamań jest monitorowanie. Systemy wykrywania włamań działają w oparciu o informacje dotyczące aktywności chronionego systemu. Wspólczesne systemy IDS analizują na bieżąco aktywność w sieci, starsze działały off-line.

Dlaczego możliwe jest ich działanie ?

Włamanie do systemu ma najczęściej przebieg dwu etapowy :

Systemy IDS analizują działalność w newraligicznych punktach sieci. Pozwalają wykryć włamywacza zarówno podczas prób penetracji systemu(detektory skanowania portów) jak również po wtargnięciu(analizatory logów,analizatory anomali).

Architektura systemu IDS

W skład systemu IDS wchodzą cztery główne komponenty:

Powyższy rusunek przedstawia schemat komunkacji pomiędzy poszczególnymi komponentami

Metody detekcji.

Problemy jakie napotyka technologia IDS

 

 

 




·  Mechanizmy obronne zintegrowane z OS


·  SElinux

Security Enhanced Debian GNU/Linux

Bezpieczeństwo systemów komputerowych jest tematem aktualnym niemal od czasów pierwszych komputerów. Dziś, w dobie Linuksa - większość jego użytkowników zapytanych o powód wyboru systemu GNU/Linux - wymienia jednym tchem wolność, niezawodność i bezpieczeństwo. Oczywiście porównująć praktyczne bezpieczeństwo GNU/Linuksa np. z alternatywnymi systemami z Redmond - Linuks wypada świetnie.

Niestety tradycyjny system typu UNIX posiada dość zawodne mechanizmy bezpieczeństwa. Zwykły błąd w jednym programie może oddać nasz system w ręce włamywaczy. Tak wcale nie musi być! Pomysłow na uzdrowienie sytuacji dyskutowano wiele. Jednym z nich jest projekt o nazwie SELinux [SELinux] - Security Enchanced Linux, co w wolnym tłumaczeniu może brzmieć:Linux o ulepszonym bezpieczeństwie.

Jeden z wieloletnich deweloperów Debiana a także aktywny uczestnik projektu SELinux - Russell Cocker - zdecydował się przygotować i udostępnić pakiety SELinux dla Debiana. O tym czym jest SELinux, co daje i jaki jest jego status w projekcie Debiana - opowie poniższy artykuł. A zatem - zaczynamy!

Czym jest SELinux i w czym jest lepszy?

SELinux jest projektem w ramach którego wzbogacono system GNU/Linux o mechanizmy obowiązkowej kontroli dostępu (ang. mandatory access control). W jądrze umieszczono nowe komponenty, które w zamyśle zostały stworzone dla polepszenia bezpieczeństwa systemu operacyjnego Fluke [Flask]. W ramach projektu dostosowano również kod wielu programów systemowych tak, aby były one w stanie korzystać z dobrodziejstw architektury SELinux. Wreszcie opracowano definicje uprawnień poszczególnych programów, tak aby z jednej strony mogły one wypełniać swoje zadania, a z drugiej - na wypadek błednego ich działania - nie mogły spowodować dużych szkód w bezpieczeństwie systemu i jego danych.

W normalnym systemie GNU/Linux - prawidłowe działanie systemu i jego bezpieczeństwo zależy od popranego działania jądra systemu, ale także programów składających się na system - w szczególności tych działających z prawami użytkowników systemowych, czy nawet prawami administratora. Błąd w jednym z tych elementów, lub błędna konfiguracja - w łatwy sposób prowadzą do utraty bezpieczeństwa całego systemu.

Kręte ścieżki historii

Zanim przejdziemy do szczegółów - szczypta historii. Od 1992 roku Narodowa Agencja Bezpieczeństwa (ang. NSA - National Security Agency) wraz z innymi firmami pracowała nad projektem i implementacją DTMach (ang. Distributed Trusted Mach) - wersji jądra Mach (tak - tego samego, którego do dziś jeszcze używa Hurd) z rozbudowanymi mechanizmami kontroli dostępu. Projekt był następnie kontynuowany pod nazwą DTOS (ang. Distributed Trusted Operating System), a gdy zbliżał się do praktycznego osiągnięcia stawianych celów - współpracując z uniwersytetem w Utah - stworzono projekt Flux w ramach którego przeniesiono architekturę zabezpieczeń DTOS do służacego badaniom systemu operacyjnego Fluke. Nowa wersja architektury została nazwana Flask. I to ona właśnie została zintegrowana z jądrem Linuksa tworząc projekt SELinux.

Koncepcja architektury Flask

Kontrola dostępu. Każdy proces i obiekt (plik, gniazdo, itd.) w systemie otrzymuje zestaw atrybutów bezpieczeństwa (ang. security attributes) tworzący tzw. kontekst bezpieczeństwa (ang. security context). Kontekst ten zawiera pełne dane na temat uprawnień danego obiektu. W momencie, gdy potrzebna jest kontrola uprawnień (np. gdy proces stara się otworzyć plik) funkcji kontrolującej uprawnienia przekazywane są dwa zestawy atrybutów bezpieczeństwa - w tym wypadku procesu i pliku. Na tej podstawie podejmowana jest decyzja o zezwoleniu na wykonanie operacji, lub jej odrzuceniu.

Oprócz operacji kontroli dostępu drugim istotnym zadaniem jest inicjowania praw (kontekstu bezpieczeństwa) nowo tworzonego obiektu. W tradycyjnym systemie UNIX np. przy tworzeniu nowego pliku brany jest pod uwagę identyfikator i grupa użytkownika, prawa dostępu katalogu nadrzędnego itd. W architekturze Flask początkowy zestaw parametrów nowego obiektu może być znacznie szerszy.

Należy też zwrócić uwagę, że dodatkowa informacja o kontekście bezpieczeństwa musi być gdzieś przechowywana. W przypadku pewnych danych dynamicznych, jak proces, gniazda TCP, czy pamięć dzielona - mogą być one zawsze przechowywane w strukturach jądra systemu. Jednak np. kontekst bezpieczeństwa plików czy katalogów musi być przechowywany w sposób trwały - jako rozszerzone atrybuty danego obiektu na dysku. Wymaga to współpracy ze strony systemu plików.

Wspomniana architektura zapewnia jedynie ramy dla konkretnej implementacji modeli bezpieczeństwa. A jak wyglądać może prawdziwy model bezpieczeństwa?

Model wymuszenia typów

W tym modelu zwanym TE (ang. Type Enforcement) każdy proces w systemie otrzymuje atrybut zwany domeną, a każdy obiekt - otrzymuje atrybut zwany typem. Wszystkie procesy będące w tej samej domenie są traktowane jednakowo (mają jednakowe uprawnienia), jak również wszystkie obiekty o danym typie są traktowane na równi. Dla każdej pary domeny i typu możemy określić, jakie działania mogą być podejmowane. Domena może być powiązana z kilkoma punktami wejścia - programami,które mogą być wykonywane przez użytkowników spoza domeny, a także wybranymi programami pomocniczymi i/lub bibliotekami, które są używane w ramach domeny. Pozwala to np. oddzielić programy zajmujące się pocztą od innych części systemu.

Kontrola dostępu uzależniona od roli

Tradycyjny model RBAC (ang. Role-Based Access Control) spotykany np. w systemach UNIX pozwala użytkownikom spełniać określoną role i dostarcza jednego zestawu uprawnień dla tej roli. W systemie SELinux użytkownik może posiadać nie jedną rolę, ale zestaw ról, a uprawnienia każdej z nich mogą być definiowane zestawem domen (patrz: wcześniejszy akapit). Można powiedzieć, że w modelu tym użytkownik może się przemieszczać pomiędzy różnymi domenami uprawnień - zgodnie z nadanymi mu uprawnieniami przemieszczania.

Czy to jest aż tak skomplikowane?

I tak i nie. Z jednej strony możliwosci udostępniane przez SELinuksa są ogrome i trzeba sporo pracy, aby umieć dobrze wykorzystać jego mechanizmy. Do tego służy specjalny, ale prosty język pozwalający zapisać reguły definiujące uprawnienia. Z drugiej jednak strony podstawowe mechanizmy standardowych systemów są bardzo do siebie podobne. Zatem zestawy reguł napisane przez jednych będą się nadawały dla drugich bez konieczności wprowadzania większych zmian.

Do tej pory jedyną dystrybucją wspieraną przez SELinux był RedHat. Dla niego zostały udostępnione dostosowane do SELinuksa pakiety kluczowych dla bezpieczeństwa programów (login, xdm i innych), a także reguły definiujące uprawnienia. Jednak sytuacja uległa zmianie, gdyż Russell Coker podjął się zadania dostosowania SELinuksa dla potrzeb Debiana GNU/Linuksa.

Z zaskoczenia i na własne oczy

Ci, którzy śledzą listę debian-devel otrzymali możliwość samodzielnego przetestowania skuteczności działania SELinuksa - bez instalowania żadnego pakietu. Russell podał adres komputera i hasło roota skonfigurowanej przez niego maszyny z SELinuksem. Poprosił wszystkich chętnych o sprawdzenie, czy uda im się wykonać jakiekolwiek naruszające stabilność systemu działania - posiadając możliwość działania z konta root.

Można było być mocno zdziwionym, gdy z jednej strony użytkownik root mógł bez problemu wykonać np. chroot, a z drugiej nie miał np. możliwości obejrzenia zawartości pewnych plików. Myślę, że przykład ten mocno wyrył się w pamięci wszystkich... Okazało się, że nawet mając hasło roota do komputera z odpowiednio skonfigurowanym SELinuksem - włamywacz nie możne poczynić w nim żadnych poważnych szkód.

Skąd pakiety Debiana GNU/SELinux

Aby móc korzystać z SELinuksa należy posiadać jądro z nałożoną odpowiednią łatą, a także zestaw odpowiednich dla SELinuksa pakietów. Można je pobrać z repozytoriów dodając odpowiednie wpisy do /etc/apt/sources.list:

·  woody:
deb http://www.coker.com.au/selinux/ ./

·  sarge/unstable:
deb http://www.coker.com.au/selinux/ ./

Źródła można znaleźć pod adresem http://www.coker.com.au/selinux/.

Integracja z oficjalnym jądrem - LSM

W tej chwili SELinux jest dostępny w dwóch postaciach. Jako samodzielna łata na jądro, lub jako łata wykorzystująca projekt Modułów Bezpieczeństwa Linuksa (ang. Linux Security Modules - LSM). Ponieważ LSM ma zostać zintegrowany z jądrem 2.5 - dodawanie w przyszłości funkcjonalności SELinux do jądra - będzie znacznie łatwiejsze. Należy być może przypomnieć czym jest LSM [LSM]. Jest to projekt, który samodzielnie nie polepsza stopnia zabezpieczenia systemu Linux, natomiast dostarcza infrastruktury jądra, dzięki której możliwa jest łatwa i dobrze udokumentowana integracja standardowego jądra Linuksa z różnymi systemami zabezpieczania systemu, w tym także SELinuksem.

Praktyczne zastosowania

Faktem jest - i nikt tego nie ukrywa - że projekt SELinux jest projektem badawczym, który innym pozostawia kwestie końcowych implementacji. Jednak mimo swojego mocno naukowego charakteru - zdobywa on sobie coraz większe uznanie i popularności w praktycznych zastosowaniach. Każdy z nas przy odrobinie starań może już dziś zabezpieczyć lepiej swoją maszynę przed niepowołanym dostępem z zewnątrz z powodu błedów oprogramowania. Jednak na na prawdę szerokie użycie SELinuksa przyjdzie nam jeszcze chwilę poczekać.

 

·  PaX

 

Motto:PaX to poprawka dla jądra Linuksa zapewniająca nieco spokoju umysłu użytkownikom ceniącym sobie nade wszystko bezpieczeństwo swoich systemów.

 

PaX to łata na jądro implementująca dodatkowe zabezpieczenie w postaci niewykonywalnych stron pamięci. A właściwie to lepiej zabezpieczającej

pamięć,.

 

 

PaX uniemożliwia wykonywanie niektórych fragmentów pamięci (stos, sterta), zabezpieczając system skuteczniej niż non-executable stack z Openwalla, jednakże niesie ze sobą dwie niedogodności: pierwszą jest spadek wydajności, drugą niedziałanie niektórych programów (XFree 4.x, wine, ...)

 

Różnica pomiędzy PaX a innymi poprawkami chroniącymi pamięć jest taka, że PaX nie zabezpiecza przed określonymi atakami z zewnątrz został zaprojektowany bardziej jako ochrona przed pewną generalną klasą ataków, do  tórych dochodzi z wnętrza systemu.

 

Różne klasy ataków

Mówiąc ogólnie, istnieją trzy grupy ataków, pod kątem których tworzone są poprawki wzmacniające ochronę pamięci:

■ Wprowadzenie i wykonanie dowolnego kodu (1).

■ Wykonanie istniejącego kodu w innej kolejności niż go opracowano (2).

■ Wykonanie istniejącego kodu w prawidłowej kolejności, ale ze zmienionymi danymi (3).

Ideą poprawki PaX jest ochrona przed całymi klasami ataków. Obecnie trwają prace nad klasą (1), klasa (2) jest w przygotowaniu, a klasa (3) zostanie opracowana w najbliższej przyszłości. Cechą odróżniającą PaX od innych poprawek chroniących pamięć jest to, że nie radzą one sobie w pełni z klasą (1), ignorując często klasę (2) i (3).

 

Przy pomocy list kontroli dostępu (ACL) i/lub innych mechanizmów kontroli dostępu (np. RSBAC [3]), PaX gwarantuje kompleksową ochronę przed wszystkimi odmianami ataków klasy (1). Jest to jedyna poprawka dla Linuksa chroniąca pamięć w ten sposób.

 

Randomizacja (losowość)

Jedną z cech poprawki PaX, i innych poprawek ochrony pamięci, jest randomizacja układu przestrzeni adresowej, czyli w skrócie

ASLR (Address Space Layout Randomization).

ASLR powoduje, że do różnych miejsc w pamięci systemu ładowane są różne części programu. Układ pamięci jest zmieniany przy każdym uruchomieniu programu.

Nie jest to mechanizm ochronny – nie zapewnia on żadnego mechanizmu kontroli. Dzięki niemu możemy jednak znacznie utrudnić wykorzystanie dziur w naszym systemie zabezpieczeń. Intruz będzie miał duże trudności z ustaleniem odpowiedniego układu pamięci. Poprawki tego typu różnią się między sobą pod względem ich stopnia randomizacji. Generalnie, im wyższy stopień randomizacji, tym trudniej wykonać brutalny atak na nasz

system. Obecnie poprawka PaX zapewnia użytkownikom najlepszy dostępny stopień randomizacji w systemie Linux, a jednocześnie jest dużo lepsza niż w systemie OpenBSD.

 

Kompatybilność

Aby korzystać z naszych programów na jądrze z poprawką PaX, nie musimy ich kompilowa ponownie. Większość programów będzie działać prawidłowo bez żadnych modyfikacji. Ewentualne niewielkie problemy stwarzają biblioteki.(z kodem napisanym w C)

 

 

·  OpenBSD OS

 

Wstep:

Wolnodostępny system operacyjny typu UNIXBSD (oparty na systemie 4.4BSD )zgodny z normą POSIX. Projekt powstał w 1996 roku jako efekt rozłamu w zespole NetBSD, jego inicjatorem był kanadyjski programista Theo de Raadt.

 

Chronologia

Pierwsza wersja systemu o numerze 2.0 ukazała się 18 października 1996.29 października 2004 ukazała się najnowsza aktualnie wersja o numerze 3.6 (http://www.openbsd.org/36.html).

Charakterystyka                                          

Nacisk przy tworzeniu systemu został położony przede wszystkim na bezpieczeństwo. Po rozłamie przyjęty za bazę projektu kod NetBSD został poddany audytowi w celu wykrycia i usunięcia wszelki dziur i błędów, które mogłyby zagrozić bezpieczeństwu systemu.

Wysiłki tworców OpenBSD skupiają się na przenośności, standaryzacji, usuwaniu błędów,proaktywnym bezpieczeństwie oraz zintegrowanej kryptografii. Proaktywne bezpieczenstwo opiera się na pełnej jawności bugów (OpenBSD stosuje jako nieliczny politykę Pełnej jawności) i ich natychmiastowym usuwaniu. Natomiast stosowanie zintegrowanej kryptografii powoduje, że twórcy OpenBSD uznali kryptografię za element numer jeden w wielu miejscach systemu.

Domyślnie wszystkie usługi dostępne w systemie, a które nie są niezbędne do jego działania, są zdeaktywowane (motto: Secure by Default). Stosuje zaawansowane metody kryptograficzne. Dzięki temu OpenBSD od początku mogło być wyposażone w takie usługi, jak SSH (wolna wersja OpenSSH) czy SSL OpenSSL).

Kryptografia w OpenBSD obejmuje:

·        Kryptograficzne funkcje haszujące

·        Kryptograficzne wsparcie dla sprzetu

·        Specjalne procedury kryptograficzne dla wszelkich danych przeplywających w systemie(jeden klucz do kodowania i odkodowania zamiast tradycyjnych dwóch kluczy)

Dziedzictwo po NetBSD zaowocowało sporą przenośnością systemu (poszczególne wydania OpenBSD powstawały na bazie portów NetBSD). Obecnie jest on dostępny dla następujących platform: i386, SPARC, SPARC64, HP300. Amiga, Mac68k, MacPPC, Mvme68k,Alpha,VAX. Zarzucone platformy obejmują: Sun3 (do wersji 2.9), ARC, Mvme88k, PMax.

OpenBSD pozwala uruchamiać binaria skompilowane dla następujących systemów: SVR4, Solaris, FreeBSD, Linux, BSD/OS, SunOS oraz HP-UX

Zastosowania

Powszechnie stosowany jako system do tworzenia systemów ścian ogniowych (firewall), serwerów dostępowych czy bramkowych podłączających w bezpieczny sposób mniejszesieci do Internetu.

1.4 – Dlaczego  używać OpenBSD?

Czy OpenBSD przewyższa inne wolne systemy z rodziny UNIX. Jest to pytanie bez odpowiedzi.

Poniżej znajduje się kilka powodów, które twórcy systemu przytaczają jako argumenty, przemawiające za używaniem OpenBSD. Jednak na pytanie "Czy OpenBSD jest systemem dla mnie?", każdy musi odpowiedzieć sobie osobiście.

 

 

Informacje techniczne

Jądro systemu - monolityczne, typu UNIX.Powłoka - każda zgodna z POSIXSystem plików - BerkeleyFFS. Format binariów - obecnie ELF, do wersji 3.4 a.out.

Dostępność

Wolny i darmowy system operacyjny rozprowadzany z pełnym kodem źródłowym na licencji BSD.