Nowoczesne metody bezpieczeństwa serwerów na przykładzie serwerów DNS

Kopeć Damian

Akademia Podlaska

Streszczenie

Niniejszy artykuł stanowi zbiór informacji na temat najczęściej stosowanych technik ataków na serwery. Z uwagi na ogromną różnorodność serwerów zagadnienie zostało omówione na przykładzie serwerów DNS. We wstępie praca dostarcza czytelnikowi podstawowych informacji niezbędnych do zapoznania się z tematem. W dalszej części zostały poruszone zagadnienia najczęściej stosowanych metod ataków na DNS-y. Artykuł jednocześnie omawia sposoby zabezpieczania serwerów przed atakami oraz stanowi zbiór porad dla czytelnika co powinien robić, aby ustrzec się przed zostaniem ofiarą ataku. W końcowej części zebrane zostały informacje na temat sztucznych systemów immunologicznych jako jednej z możliwych dróg rozwoju nowoczesnych systemów bezpieczeństwa.

• 1. Wstęp

• "Przez lata wiedzieliśmy, że jest to możliwe. Teraz czas się przed tym bronić". Takimi słowy rozpoczął swą wypowiedź Dan Kaminsky na konferencji „Defcon”, która to miała miejsce 31.07.2004 roku. Zdanie to odnosiło się do możliwości atakowania serwerów DNS. Ataki na serwery DNS stają się coraz częstszą formą wyłudzania pieniędzy od przeciętnych użytkowników Internetu. W dobie elektronizacji oraz zdalnego wykonywania wielu czynności (np. Internetowe konta bankowe, operacje bezgotówkowe itp.) walka z oszustami, starającymi się okraść nieświadomych zagrożenia ludzi, stała się koniecznością. Należy zdać sobie sprawę, że system DNS został zaprojektowany wiele lat temu przez naukowców. Nie przewidzieli oni istnienia światowej sieci używanej do prowadzenia poważnych operacji. Istnieje wiele rodzajów i odmian ataków na serwery DNS np. cache poisoning. Jednak na każdy nowy atak administratorzy starają się odpowiadać nową formą obrony. Zagadnienia omawiające metody ataków oraz obrony zostaną bardziej szczegółowo omówione w dalszej części tego dokumentu. Aby bliżej zrozumieć istotę problemu, należy najpierw posiąść podstawową wiedzę związaną z tym zagadnieniem. W tym miejscu wytłumaczone zostanie pojęcie serwera DNS oraz jego rodzaje, przybliżony zostanie sposób działania tychże serwerów. Skrót DNS wywodzi się z języka angielskiego i oznacza Domain Name System, czyli w wolnym tłumaczeniu System Nazw Domenowych. Jest to system serwerów oraz protokół komunikacyjny służący do tłumaczenia nazw mnemonicznych (np. google.pl) na odpowiednie adresy IP. Możemy wyróżnić dwa podstawowe rodzaje serwerów DNS: BIND(w różnych wersjach) oraz djbdns. BIND (ang. Berkeley Internet Name Domain) został stworzony na Uniwersytecie Berkeley w Kalifornii. Obecnie jest zarządzany i rozwijany przez Internet Systems Consortium(w skrócie ISC) . Djbdns został stworzony przez Daniela J. Bernsteina. Jest zestawem programowym powstałym w odpowiedzi na błędy i niedoskonałości szeroko stosowanych serwerów BIND. Djbdns składa się z trzech aplikacji:

• tinydns (udp/53) - serwer DNS autorytatywny

• dnscache (tcp/53 i udp/53) - serwer cache dla systemu DNS

• axfrdns (tcp/53) - serwer udostępniający strefy do transferu dla wskazanych maszyn (np. dla serwerów secondary, itp.)

• Najważniejsze cechy serwerów DNS:

• - Nie ma jednej centralnej bazy danych adresów IP i nazw. Najważniejsze jest te 13 serwerów, które są rozrzucone na różnych kontynentach.

• - Serwery DNS przechowują dane tylko wybranych domen.

• - Każda domena ma co najmniej 2 serwery DNS obsługujące ją, jeśli więc nawet któryś z nich będzie nieczynny, to drugi może przejąć jego zadanie.

• - Serwery DNS przechowują przez pewien czas odpowiedzi z innych serwerów (ang. caching), a więc proces zamiany nazw na adresy IP jest często krótszy niż w podanym przykładzie.

• - Każdy komputer może mieć wiele różnych nazw.

• - Czasami pod jedną nazwą może kryć się więcej niż 1 komputer po to, aby jeśli jeden z nich zawiedzie, inny mógł spełnić jego rolę.

• - Jeśli chcemy przenieść serwer WWW na inny szybszy komputer, z lepszym łączem ale z innym adresem IP, to nie musimy zmieniać adresu WWW strony, a jedynie w serwerze DNS obsługującym domenę poprawiamy odpowiedni wpis.

• - Protokół DNS posługuje się do komunikacji głównie protokołem UDP

• - Serwery DNS działają na porcie 53.

• 2. Metody ataku na serwer DNS

Istnieje kilka form ataków na serwery DNS. Jednakże aby dobrze zrozumieć ich ideę należy najpierw opisać jedną z metod ataku na użytkowników Internetu, nie mającą bezpośrednio związku z DNS - ami. Mowa tutaj o phishingu.[1] Cytując za Mariuszem Tomaszewskim (Hakin9 nr 4/2005): „Phising to forma ataku komputerowego polegająca na przechwyceniu poufnych danych użytkownika, najczęściej w celu kradzieży pieniędzy z jego konta internetowego”. Pochodzenie nazwy nie jest do końca jednoznaczne. Część osób tłumaczy phising jako password harvesting fishing co po polsku znaczy łowienie haseł. Inni natomiast uważają, iż nazwa ta pochodzi od osoby Briana Phisha, który rzekomo jako pierwszy, stosując techniki psychologiczne, wykradał numery kart kredytowych (lata 80-te). Natomiast jeszcze inni twierdzą, że postać Briana Phisha to tylko fikcja, służąca do identyfikacji skamerów między sobą. Termin „phising” narodził się w połowie lat 90-tych ubiegłego wieku w Stanach Zjednoczonych. Najpopularniejszą formą łączenia z Internetem było połączenie modemowe. Jeden z największych dostawców Internetu AOL (American Online) zakładał konta swym klientom i naliczał opłaty za ilość czasu spędzonego na surfowaniu (aby korzystać z Internetu użytkownik musiał się zalogować). Jednocześnie wraz z taką formą naliczania opłat pojawili się oszuści, którzy wykorzystywali naiwność i łatwowierność innych. Atak polegał na rozsyłaniu wiadomości (e - mail) do użytkowników i podawaniu się za jednego z pracowników AOL. Treść wiadomości wyglądała mniej więcej tak: „ Jestem administratorem AOL. Zauważyliśmy niepokojące nadużycia na Twoim koncie. W celu weryfikacji Twoich danych prosimy o podanie loginu i hasła w przeciwnym razie Twoje konto zostanie zablokowane”. Wielu użytkowników wysyłało swoje dane, a oszuści bezkarnie korzystali z Internetu na ich rachunek, niekiedy wykorzystywali tak zdobyte konta w celach przestępczych (np. rozsyłanie spamu). W chwili obecnej phishing uległ pewnym modyfikacjom. Używany jest przede wszystkim w celach zarobkowych. Celem ataków stały się głównie banki oraz instytucje finansowe. Dzisiejszy atak przebiega w następujący sposób: atakujący wysyła spam do dużej ilości osób podając się za pracownika banku. W mailu znajduje się odsyłacz do fałszywej strony łudząco podobnej do autentycznej. Wpisanie danych na tej stronie powoduje ich przechwycenie przez phishera i wysoce prawdopodobne ich dalsze wykorzystanie w celu włamania się na konto osoby oszukanej. Zaawansowaną formą phisingu jest pharming. Metoda ta polega na sfałszowaniu adresu ip strony, która interesuje pharmera ( najczęściej bank lub inna instytucja finansowa). Następnie taki nieprawdziwy rekord wprowadzany jest do pamięci cache serwera DNS w celu przekierowania osób chcących skorzystać z usług banku na podrobioną stronę. W konsekwencji oczywiście prowadzi to do kradzieży ich poufnych danych niezbędnych do logowania na kontach. W odróżnieniu od phisingu w tej metodzie atakujący nie musi rozsyłać wiadomości do potencjalnych ofiar, więc nie wzbudza podejrzeń. Pharming stanowi zagrożenie dla większej ilości osób, gdyż atakowany jest jeden serwer DNS a korzysta z niego bardzo duża ilość osób. W ataku typu phising zagrożeni byli jedynie klienci banku, do których dotarł odpowiedni e - mail. Przy czym należy zaznaczyć, że osoby które dostały wiadomość a nie są klientami banku mogły zgłosić próbę ataku. Wobec tego nasuwa się wniosek, iż pharming jest metodą o wiele niebezpieczniejszą a zarazem trudniejszą do wykrycia. Atak ten można przeprowadzić zarówno na pojedynczy komputer jak i na serwer DNS. Pierwszy sposób polega na modyfikacji pliku, znajdującego się na każdym komputerze z systemem operacyjnym Windows oraz na stworzeniu fałszywej strony. W pliku tym znajdują się adresy serwerów oraz adresy IP najczęściej odwiedzane przez ofiarę. Modyfikacja ich powoduje, że użytkownik zamiast na stronę swojego banku wejdzie na sfałszowaną stronę, wyglądającą dokładnie tak, jak oryginał. Przykładem działania tego typu jest: Trojan.Win32.DNS.Changer. Natomiast druga metoda została już opisana i polega na wysłaniu do serwera DNS fałszywego rekordu wiążącego nazwę domeny z adresem IP. Serwer DNS otrzymując taką informację zapamiętuje ją na pewien okres czasu (określony jest on przez parametr Time To Live - TTL) i będzie zwracał klientom zapamiętany błędny adres IP. Jednym ze skutecznie przeprowadzonych ataków był atak w 2004 roku na domenę ebay.de. Ten rodzaj pharmingu nosi nazwę cache poisoning. Możemy wyróżnić trzy odmiany cache poisoningu. Są to: atak klasyczny, zmodyfikowany atak klasyczny oraz atak dnia narodzin).

• 2.1 Atak klasyczny

W klasycznym ataku napastnik kieruje fałszywe zapytanie do serwera DNS. W odpowiedzi na to zapytanie wysyła pewną liczbę (n) nieprawdziwych odpowiedzi. Dokładniej przebiega to w ten sposób, że serwer DNS kieruje zapytanie do serwera autorytatywnego obsługującego domenę, o którą pyta atakujący. Losowo ustawia w tym zapytaniu numer identyfikacyjny ID. Zakres wartości tego numeru to 1 - 65535. Oczywistym jest fakt, że im więcej sfałszowanych odpowiedzi wyśle napastnik tym większą będzie miał szansę na zatrucie pamięci cache atakowanego serwera. Prawdopodobieństwo powodzenia takiego ataku opisuje wzór:

• 
  

• Wobec tego jeśli atakujący wyśle 65535 pakietów to prawdopodobieństwo ataku będzie wynosiło 1. Na szczęście numer ID nie jest jedynym parametrem, jednoznacznie potwierdzającym prawidłowość odpowiedzi. Właściwą wartość musi przyjąć również port źródłowy, port docelowy, jak również adres źródłowy autorytatywnego serwera. Ustawienie właściwego adresu źródłowego nie jest zbyt trudne, gdyż atakujący wie jakie serwery odpowiadają za daną domenę. Jeśli jest kilka serwerów sprawa się nieco komplikuje, gdyż konieczne jest przewidzenie, który serwer został odpytany. W celu uzyskania tej informacji napastnik może wykorzystać Time To Live umieszczany w pakietach zwrotnych od serwerów autorytatywnych. Jeżeli wielkości parametru TTL dla każdego serwera są różne to znany jest czas po jakim tylko jeden serwer będzie zawierał informacje na temat danej domeny. Zatem wnioskując dalej atakujący będzie wiedział, pod który serwer autorytatywny powinien się podszywać.

• Zapytania zawsze wysyłane są na port 53, który jest portem domyślnym usługi DNS. Ten sam port jest również portem źródłowym serwera autorytatywnego odpowiadającego na zapytanie serwera atakowanego. Jedynym problemem jaki może napotkać w tym miejscu napastnik jest ustalenie portu docelowego w serwerach djbdns. W przypadku serwerów BIND (zarówno w wersji 8 jak i 9) nie jest konieczne ustalenie portu docelowego, gdyż akceptują one odpowiedzi wysłane na port 53. Natomiast jeśli chodzi o serwery djbdns to klasyczny atak cache poisoning jest praktycznie niemożliwy do przeprowadzenia, gdyż serwer dla każdego zapytania generuje losowo port źródłowy, a ponadto aby odpowiedź była uznana za prawdziwą musi nadejść na ten sam port, z którego zostało wysłane zapytanie.

• 2.2 Zmodyfikowany atak klasyczny

• Atak ten polega na generowaniu w pętli określonej liczby fałszywych odpowiedzi (ilość istotnie mniejsza od 65535) z losowo wygenerowanymi numerami ID. Należy uwzględnić fakt, iż muszą być to zawsze te same numery ID przy każdym nowym obrocie pętli. Dwa zasadnicze czynniki, czyli szybkość łącza atakującego oraz ilość czasu upływająca pomiędzy kolejnymi zapytaniami kierowanymi od serwera atakowanego do serwerów autorytatywnych, wpływają na ilość każdorazowo wysłanych nieprawdziwych odpowiedzi. Na każde zapytanie serwera atakujący wysyła stałą ilość wygenerowanych odpowiedzi, przy czym odpowiedzi te muszą dotrzeć przed upływem czasu opisanego powyżej i wygenerowaniem kolejnego zapytania. Wszystkie takie wysłane paczki pakietów zawierają takie same zestawy numerów ID. Jest to metoda dopasowywania przez napastnika numerów ID tworzonych przez niego odpowiedzi do numerów ID zapytań generowanych przez atakowany serwer DNS.

• Krótko w punktach taki atak może wyglądać następująco:

- napastnik generuje losowo pewną liczbę numerów ID (dobiera ją wg Wyżej wymienionych dwóch czynników)

- przeprowadzany jest atak DDoS (DDoS (ang. Distributed Denial of Service) atak na system komputerowy lub usługę sieciową w celu uniemożliwienia działania poprzez zajęcie wszystkich wolnych zasobów przeprowadzany równocześnie z wielu komputerów) na autorytatywny serwer DNS w celu opóźnienia nadejścia od niego odpowiedzi na zapytanie serwera atakowanego

- atakujący generuje zapytanie o stronę, którą chce podmienić

- rozpoczyna się wysyłanie pakietów przygotowanych przez atakującego

- w sytuacji gdy atakowany serwer wyśle zapytanie o ID zgodnym z ID pakietu wygenerowanego przez atakującego to atak się powiedzie, a więc pamięć cache uzyska fałszywy rekord odwzorowujący IP na domenę.

• 2.3 Atak dnia narodzin

Nazwa atak dnia narodzin jest tłumaczeniem angielskiego odpowiednika birthday attack. Wywodzi się ona z klasycznego problemu matematyki zwanego paradoksem dnia narodzin. Paradoks ten związany jest z pytaniem: Ile osób należy wybrać, żeby prawdopodobieństwo, iż przynajmniej dwie z nich mają urodziny tego samego dnia, wynosiło więcej niż ½. Cały paradoks polega na tym, iż każdemu wydaje się, że liczba ta powinna być duża. Natomiast odpowiedź wynosi: 23. Ogólnie można powiedzieć, że jeśli losowo przyporządkujemy każdemu obiektowi jedną z n etykiet, to żeby prawdopodobieństwo, że dwa obiekty będą oznaczone taką samą etykietą było większe od jednej drugiej trzeba zbioru obiektów o liczności rzędu
. Bazując na tym twierdzeniu można go zaadaptować do problematyki ataku na serwer DNS. Okazuje się, że żeby prawdopodobieństwo tego, że przynajmniej jedno zapytanie i jedna odpowiedź będą miały ten sam numer ID, było zbliżone do wartości 1, należy wysłać 302 fałszywe odpowiedzi na 302 zapytania serwera DNS. Atak dnia narodzin polega na wysyłaniu n fałszywych odpowiedzi na n zapytań ( w ataku klasycznym było to n odpowiedzi na jedno zapytanie). Zapytania te dotyczą odwzorowania tej samej domeny na jej IP. W celu lepszego zabezpieczenia się przed wykryciem ataku włamywacze często korzystają z wielu losowo generowanych adresów IP. Część serwerów DNS na każde takie zapytanie wygeneruje zapytanie, z losowo wygenerowanym numerem ID, do serwera autorytatywnego. Równocześnie atakujący wyśle taką samą ilość odpowiedzi w kierunku serwera atakowanego, również z losowo wybranymi ID. Prawdopodobieństwo powodzenia jego ataku jak już wcześniej wspomniałem jest dość wysokie i wyraża się wzorem:

• 
  

• t - oznacza wszystkie możliwe pakiety będące odpowiedzią

Porównując atak klasyczny z atakiem dnia narodzin można dojść do wniosku, że ten drugi jest o wiele bardziej niebezpieczny. Aby prawdopodobieństwo sukcesu w ataku klasycznym było równe 1 potrzeba 65535 różnych ID. Natomiast w birthday attack już przy ilości 700 różnych ID prawdopodobieństwo zbliża się do 1 (dokładniej wynosi 0,97608). Z uwagi na niewielką konieczną ilość wysyłanych ID, a zatem niewielki czas potrzebny na udzielenie fałszywej odpowiedzi niestety atak ten z powodzeniem może być przeprowadzany w sieci Internet. Należy pamiętać, że zarówno dla tego ataku jak i dla wcześniej opisywanych nieprawdziwa odpowiedź od atakującego musi uprzedzić odpowiedź autorytatywnego serwera nazw. Istnieją wcześniej wspomniane mechanizmy opóźnienia odpowiedzi serwera autorytatywnego jak chociażby atak DDoS. Bliższe informacje na temat ataków tego typu można znaleźć pod adresem WWW: http://news.zdnet.com/2100-9595_22-979650.html.

• 2.4 Metody wspomagające i pokrewne

• Wykorzystanie mechanizmu IDN

Jedną z ciekawszych metod przekierowania użytkownika na podstawioną stronę jest wykorzystanie mechanizmu IDN (International Domain Name), który umożliwia wykorzystanie znaków narodowych w nazwach domenowych. Wystarczy aby atakujący zastąpił tylko jedną literę z alfabetu łacińskiego inną. Link będzie wyglądał identycznie z pierwowzorem natomiast będzie to zupełnie inna strona. Najgorsze jest to, iż do tej pory nie znaleziono skutecznej metody walki z takimi działaniami. Jedyne co może zrobić użytkownik to wyłączyć mechanizm IDN.

• Wykorzystanie transferu stref

Rozpatrzmy sieć z wykorzystaniem kilku serwerów DNS. Każdy adres musi być przechowywany przez co najmniej dwa serwery. Jeden z nich jest podstawowym serwerem a drugi spełnia rolę serwera zapasowego. Zauważyć należy, że przy zmianie jakiegokolwiek wpisu serwer zapasowy musi dokonywać transferu całej strefy z serwera podstawowego. Powodem takiego działania jest utrzymanie spójności wpisów w obydwu serwerach oraz aktualności wpisów w serwerze zapasowym. Cały problem jest w tym, że plik strefy może dostać się w niepowołane ręce, przez co rekordy oraz informacje o adresach IP znajdą się w posiadaniu napastnika.

• Wykorzystanie pola BIND CHAOS

Jak sama nazwa wskazuje pole takie istnieje jedynie w serwerach typu BIND, a więc po raz kolejny ukazane jest większe bezpieczeństwo serwera djbdns. W polu tym przechowywane są dodatkowe informacje dotyczące samego serwera. Z informacji tych standardowo użytkownicy nie korzystają, natomiast dla włamywacza niejednokrotnie dostarcza ono wielu cennych informacji oraz wskazówek. Pole CHAOS przechowuje np. informacje na temat wersji serwera, a więc haker, chcący się włamać uzyskawszy takie dane, może lepiej oraz łatwiej dopasować narzędzia ataku. W wersji BIND 9.x autorzy serwera dodali swoje nazwiska do pola CHAOS, wnioskując: jeżeli serwer na zapytanie o autorów zwróci nazwiska tzn. że mamy do czynienia z BIND-em w wersji 9.x konsekwencje zwrócenia tychże danych są podobne jak w przypadku zwrócenia informacji o wersji.

• Wykorzystanie dodatkowych rekordów (dodatkowych danych)

Podobnie jak z polem CHAOS sytuacja wygląda z dodatkowymi rekordami serwera. One także mogą dostarczyć i co gorsze dostarczają informacji ułatwiających przeprowadzenie skutecznego ataku na serwer. Oto niektóre z tych pól wraz z opisem danych jakie zawierają:

• SOA (Start of Authority) - zawiera adres email administratora DNS
  A (Address) - adres IP należący do nazwy komputera
  PTR (Pointer) - nazwa hosta dla danego adresu IP
  HINFO - architektura i system operacyjny hosta
  TXT - inne informacje opisujące hosta
  RP - adres email osoby odpowiedzialnej za dany komputer

• Chyba najbardziej niebezpieczną informacją jaką można uzyskać z tych pól jest informacja na temat wersji systemu operacyjnego. Dzięki takim danym haker może dostosować formę ataku oraz narzędzia do systemu operacyjnego.

• Polecenie służące do pozyskania wszystkich danych z dodatkowych rekordów:

• host -t `*' przyklad.pl

3. Metody obrony przed atakami

Rozwój ataków na serwery DNS wymusił konieczność obrony przed napastnikami. Jednak pamiętać należy, że działania jedynie administratorów DNS nie wystarczą. Zarówno producenci przeglądarek, administratorzy jak zwykli użytkownicy powinni starać się jeśli nie uniemożliwiać, to utrudniać przeprowadzenie ataków. Należy zadać pytanie co każda z tych grup może zrobić dla zwiększenia bezpieczeństwa.

• 3.1 Administratorzy serwerów WWW

W celu zwiększenia bezpieczeństwa administratorzy powinni zastanowić się nad zastosowaniem SSL (służy do uwierzytelniania użytkowników). Użycie protokołu HTTPS oraz certyfikatów także powinno pozytywnie wpłynąć na bezpieczeństwo. Samo zastosowanie wyżej wymienionych mechanizmów nie daje gwarancji bezpieczeństwa. Wymaga ono również od użytkowników pewnych działań. Powinni oni sprawdzać certyfikat SSL danej strony, gdyż należy zdać sobie sprawę, że także certyfikat może zostać spreparowany. Oczywiście sprawdzenie powinno być wykonane przed jakimikolwiek innymi działaniami, również przed zalogowaniem. Jeśli przeglądarka zwraca alarm nieprawidłowości certyfikatu użytkownik powinien zastanowić się nad logowaniem, najlepiej dla własnego bezpieczeństwa powinien opuścić stronę.

• 3.2 Operatorzy usług DNS

[3]Operatorzy serwerów DNS mają największe możliwości zabezpieczenia swych serwerów przed atakami. Mogą to uczynić poprzez zastosowanie odpowiedniej architektury oraz poprzez odpowiednią konfigurację serwera.

• Architektura

Pierwszym możliwym zabezpieczeniem jest uruchomienie dwóch serwerów nazw dla swojej jednej strefy (split-split DNS). W architekturze tej autorytatywny serwer nazw umieszczony jest w strefie zdemilitaryzowanej tzn. za firewallem. Obsługuje jedynie zapytania nierekurencyjne przychodzące z Internetu. Natomiast serwer DNS działa w sieci lokalnej i jedyną rolą jaką spełnia jest obsługa zapytań rekurencyjnych przychodzących z sieci lokalnej, w której jest uruchomiony.

• Blokada zapytań rekurencyjnych

Jeśli niemożliwe jest zastosowanie architektury split-split należy zablokować obsługę zapytań rekurencyjnych przychodzących z Internetu przez serwer DNS. Należy pamiętać, że opcja recursion domyślnie jest ustawiona na yes. W serwerach BIND wersji 8 i 9:

• options

• {

• recursion no;

• };

• Istnieje również możliwość zdefiniowania grupy komputerów, dla których dostępna będzie możliwość rekurencyjnych zapytań. Parametr za to odpowiadający to: allow -recursion. W celu określenia grupy użytkowników, trzeba zdefiniować acl (Access Control List - lista kontroli dostępu) i użyć jej we wspomnianej wcześniej opcji allow - recursion. Przykład definiowania acl i zastosowania jej do udostępnienia rekurencyjnych zapytań:

• acl listka {192.168.4.0/24};

• options

• {

• allow - recursion {listka; };

• };

• Wyłączenie pamięci cache

Kolejnym sposobem na utrudnienie ataków jest rezygnacja z pamięci podręcznych w serwerach DNS. Należy jednak pamiętać o zasadniczej wadzie takiego rozwiązania, a mianowicie zastosowanie tej metody w znacznym stopniu może zwiększyć ruch w sieci a co za tym idzie może spowolnić działanie programów wykorzystujących serwery DNS.

• DNSSEC

Inną metodą może być zastosowanie protokołu DNSSEC. Jest to protokół oparty o cyfrowe podpisy, który wykorzystuje mechanizmy kryptograficzne bazujące na kluczach publicznych, co potencjalnie stwarza możliwość zabezpieczenia całej drzewiastej struktury systemu DNS. Protokół zabezpiecza informacje DNS przed sfałszowaniem i modyfikacją, oferując dodatkowo możliwość wykorzystania go jako infrastruktury do dystrybucji kluczy publicznych. Protokół DNSSEC umożliwia zapewnienie integralności i możliwość weryfikacji autentyczności pozyskanych danych. Klient systemu może mieć pewność, że otrzymane przez niego dane są wiarygodne i nie zostały zmienione w trakcie transportu ze źródła. Protokół definiuje zabezpieczanie strefy a nie serwera, dzięki czemu nawet w przypadku złamania zabezpieczeń jednego z serwerów autorytatywnych dla danej strefy, bezpieczeństwo systemu jako całości zostaje zachowane.

• Ograniczenie transferu stref

Dokonując odpowiednich konfiguracji serwera BIND administratorzy mogą nas uchronić przed transferem stref do niepowołanych komputerów. Otóż dopisując opcje allow-transfer administrator określa komputery, do których transfer strefy będzie dozwolony. Przykładowy listing:

• options

• {

• allow-transfer{83.10.25.20;}

• }

Można również zdefiniować listę analogicznie do listingu odnoszącego się do rekurencyjnych zapytań (acl listka {192.168.4.0/24};). Jeśli chodzi o serwery typu djbdns sytuacja wygląda lepiej. W celu określenia konkretnych komputerów, dla których będzie dozwolony transfer stref, można zastosować mechanizm axfrdns. Jeśli nie są zastosowane serwery BIND jako serwery zapasowe to wystarczy zastosowanie rsync, w celu zsynchronizowania wszystkich stref automatycznie.

• Wyłączenie dodatkowych informacji

W celu zabezpieczenia się przed otrzymywaniem danych z pola CHAOS przez potencjalnych napastników, specjaliści zalecają wyłączenie obsługi tego pola, twierdząc, iż można tego dokonać np. poprzez użycie widoków. W celu zabezpieczenia serwera przed podawaniem informacji z dodatkowych rekordów zalecane jest uczynienie tych rekordów niepublicznymi. Natomiast jeśli chodzi o podawanie wersji serwera można dopisać do pliku konfiguracyjnego opcję, która na zapytanie o wersję będzie wyświetlała ustawiony tekst.

• options

• {

• version „ten tekst pojawi się użytkownikowi po zapytaniu o wersję serwera”;

• } ;

• Wykorzystanie Sygnatur Transakcji

Sygnatury Transakcji (TSIG) są wykorzystywane przy transferze stref i mają na celu zabezpieczenie strefy przed dostaniem się jej w niepowołane ręce. W procesie wymiany danych używane jest szyfrowanie oraz infrastruktura kluczy w celu potwierdzenia tożsamości serwerów przy nawiązywaniu połączenia.

• Ograniczenie zapytań

W serwerach BIND w wersji 8 oraz 9 istnieje możliwość przypisania listy adresów IP komputerów, na których zapytania będą udzielane odpowiedzi. Komputery nie znajdujące się na liście odpowiedzi od serwera nie otrzymają. Ogranicza to możliwość połączenia się komputera spoza sieci. Dokonać tego można w sposób następujący:

• options {

• allow-query {lista adresów IP};

• };

• Uruchomienie BINDa ze zmniejszonymi prawami

Kolejną czynnością, której wykonanie pozwoli zwiększyć bezpieczeństwo serwera jest jego uruchomienie z jak najmniejszymi prawami, pozwalającymi pracować administratorowi. Ustawienia takie znane są jako least privilege. Dzięki takim opcjom, jeśli hakerowi uda się włamać na serwer ,nie będzie miał on wszystkich praw dostępnych dla administratora zalogowanego na konto root. W serwerach BIND w wersji 8.1.2 i późniejszych istnieje możliwość zmiany użytkownika oraz grup, w których serwer pracuje.

• Ograniczenie automatycznych aktualizacji

Chociaż dynamiczne aktualizacje są użyteczne do ograniczenia opóźnienia standardowo występującego przy statycznej obsłudze stref DNS, stanowią one dodatkowe ryzyko dla integralności danych o strefach. Przyczyną zagrożenia jest to, że autoryzowany aktualizator może:

• • dodawać nowe wpisy do strefy

• • skasować dowolne wpisy ze strefy

• • zmodyfikować dowolne wpisy w strefie

W związku z tym administratorzy serwerów pozwalających na automatyczne aktualizacje powinni rozważyć ograniczenia mające na celu zapobiegnięcie potencjalnym nadużyciom.

Tak jak w przypadku dowolnego mechanizmu autoryzacji bazującego na adresach IP, należy pamiętać że adres IP może być łatwo sfałszowany. Co więcej, automatyczne aktualizacje standardowo używają UDP jako protokołu transportowego, więc jeden spreparowany pakiet może wystarczyć do uszkodzenia danych. Serwery, które używają adresów IP jako podstawowej metody autoryzacji dla automatycznych aktualizacji DNS, powinny zaimplementować mechanizmy sprawdzające autentyczność IP aby ograniczyć ryzyko nieautoryzowanej modyfikacji danych.

• Wyłączenie opcji glue fetching (tylko BIND 4.9 i 8)

• Jeśli serwer nazw zwraca w odpowiedzi rekordy NS, ale jako dodatkowych danych, nie posiada odpowiadających im rekordów A, może spróbować je uzyskać. To zachowanie jest standardowym dla wersji BIND starszych niż 9, i jest potencjalnym źródłem zatruć cache. Poprzez wyłączenie glue fetching można usunąć tę lukę, eliminując możliwość pozyskania przez serwer fałszywych rekordów A.

• Aby wyłączyć glue fetching, należy użyć polecenia no-fetch-glue w BIND 4.9:

• options no-fetch-glue

• albo zmodyfikować pole fetch-glue w BIND 8:

• options {

• fetch-glue no;

• };

• Chociaż BIND 9 ma tą samą składnie co BIND 8, polecenie zostanie zignorowane, gdyż BIND 9 nie używa glue fetching w żadnym wypadku.

• Uruchomienie serwera w chroot() "prison"

Dodatkową ochronę przeciwko atakom na cały system poprzez słabości BIND można uzyskać dzięki uruchamianiu w chroot() „prison”(„jail”). Przez takie działania serwer nazw jest ograniczony do własnego podkatalogu, więc przejęty BIND nie może zagrozić reszcie systemu.

Podstawowe kroki wymagane do implementacji środowiska chroot() :

• -stworzenie nowego katalogu do uruchomiana wewnątrz (np. /var/named)

• -stworzenie odpowiednich podkatalogów

• -skopiowanie wymaganych plików do nowego katalogu, zawierających przynajmniej:

• -plik named wykonywalny

• -plik named.conf konfiguracyjny

• -pliki stref

• -plik named-xfer

• Istnieje możliwość, że wymagane będą dodatkowe biblioteki

• -uruchomienie programu z parametrem -t i ścieżka do stworzonego katalogu #named -u named -t /var/named

• Aktualizacje

Praca administratora DNS nie kończy się jedynie na właściwym skonfigurowaniu serwera. Musi być on ciągle na bieżąco, czytać literaturę, fora, strony oraz serwisy poświęcone zagadnieniom bezpieczeństwa. Ponadto zaleca się instalowanie jak najnowszych wersji serwerów, gdyż są one poprawiane i pojawiają się w nich coraz lepsze zabezpieczenia przed włamaniami. Niektórzy specjaliści i znawcy tematu zalecają wymianę serwerów BIND na djbdns, gdyż uważają je za dużo bardziej bezpieczne.

• 3.3 Użytkownicy

Użytkownicy także w pewnym stopniu mogą podnieść bezpieczeństwo korzystania z potencjalnie zagrożonych witryn. Jednym ze sposobów jest wyżej omówiona weryfikacja certyfikatów SSL. Najprostszym i zarazem najlepszym sposobem uchronienia się przed przekierowaniami na podrobione strony jest korzystanie z adresów IP zamiast adresów domenowych. Oczywiście jest ono o dużo mniej wygodne, niemniej jednak wyklucza możliwość podstawienia spreparowanej strony.

Kolejnym sposobem w jaki przeciętny użytkownik może uchronić się przed oszustwami jest korzystanie ze specjalnych narzędzi śledzących położenie geograficzne serwerów, na których znajdują się strony przez Niego odwiedzane. Lokalizacja serwera polskiego banku nie powinna wybiegać poza obszar naszego kraju. Jeżeli taka aplikacja pokazuje, że jest inaczej automatycznie jest to znak, że połączenie zostało nawiązane z nieprawidłową stroną. Przykładem działającej w ten sposób aplikacji jest Netcraft Toolbar.

• 4. Sztuczne systemy immunologiczne

[4]W ostatnich latach coraz większą rolę w budowaniu zabezpieczeń systemów informatycznych odgrywają systemy oparte o sztuczną inteligencję. Jednymi z systemów opartych o AI są sztuczne systemy immunologiczne, które opierają się o logikę działania systemów immunologicznych ssaków. Jako, że system immunologiczny żywego organizmu to niezwykle złożony mechanizm, sztuczne systemy immunologiczne implementują najprostsze zasady systemów immunologicznych.

Immunologia to nauka, której celem jest badanie odporności organizmów na zarazki, toksyny i niektóre substancje chemiczne, głównie białkowe. Za prekursorów immunologii powszechnie uważa się Ludwika Pasteura i Roberta Kocha, którzy badali złożony świat chorobotwórczych mikroorganizmów (patogenów). Jednocześnie proponowali środki wspomagające obronność organizmu. W rozumieniu przydatnym dla potrzeb informatycznych system immunologiczny możemy określić jako efektywny rozproszony system przetwarzania informacji posiadający zdolność uczenia się i adaptacji do zmiennego otoczenia. W uproszczeniu możemy powiedzieć, że systemy immunologiczny jest klasyfikatorem binarnym, którego głównym zadaniem jest rozpoznawanie struktur oraz przyporządkowanie ich do klas własnych tudzież obcych. Obiektami systemów immunologicznych są limfocyty. Wyróżniamy dwa rodzaje limfocytów: limfocyty typu T oraz typu B. Pierwsze z nich odpowiadają za rozpoczęcie akcji obronnej. Natomiast te drugie są głównymi mechanizmami zwalczania patogenów i anomalii. Poszczególne grupy limfocytów typu B specjalizują się w zwalczaniu określonych ataków. W systemach immunologicznych może także zaobserwować zjawisko udoskonalania limfocytów, dzięki czemu stają się one coraz bardziej skuteczne. Jednostki nieskuteczne bardzo szybko usuwane są z systemu, a na ich miejsce pojawiają się nowe limfocyty wyposażone w lepsze mechanizmy obronne. Oczywistym jest fakt, iż limfocyty powinny mieć wpływ destrukcyjny jedynie na struktury obce. Jednocześnie ich zadaniem jest nieuszkodzenie struktur własnych oraz ich ochrona.

Timmis oraz de Castro definiują sztuczne systemy immunologiczne jako systemy adaptacyjne, inspirowane przez immunologię teoretyczną i obserwowane immunologiczne funkcje, zasady oraz modele, które znajdują zastosowanie do rozwiązywania zadań.

• Zastosowania sztucznych systemów immunologicznych:

• -Bezpieczeństwo systemów informatycznych

• -Maszynowe uczenie

• -Sztuczne życie

• -Rozpoznawanie wzorców

• -Systemy agentowe

• -Analiza danych (np. data mining)

• -Detekcja anomalii i błędów

• -Metody szukania i optymalizacji

• -Autonomiczna nawigacja i sterowanie

• Własności systemów immunologicznych:

• -Unikalność

• -Różnorodność

• -Zdolność rozpoznawania wzorców

• -Tolerancja na błędy i szum

• -Nietrwałość

• -Brak obszarów chronionych

• -Detekcja anomalii

• -Autonomiczność

• -Integracja

• -Rozproszenie

• -Odporność na zaburzenia

• -Samoorganizacja

• -Odporność na własne błędy

• -Dynamicznie zmienny obszar kontroli

• -Wielowarstwowość

• -Uczenie się i pamięć

• -Żywotność

• -Działanie w stylu „drapieżnik - ofiara”

• 5.Bibliografia

• [1] Tomaszewski M., „Pharming - ataki DNS cache poisoning”, Hakin9 nr 4/2005

• [2] http://www.dns.pl/dnssec/theory_dnssec_in_a_nutshell.html

• [3] http://www.cert.org/archive/pdf/dns.pdf

• [4] Wierzchoń S.T., „Sztuczne systemy immunologiczne. Teoria i zastosowanie”, Akademicka Oficyna Wydawnicza Exit, Warszawa 2001

• 6.Modern methods of server security based on DNS servers.

Abstract

The following article is a set of informations about most commonly used tactics of attacking servers. Due to very broad range of available services, the subject is described basing on example of DNS servers. In the beginning, the article gives the reader some basic information necessary to understand the topic. Following most commonly used methods of attacks, and a set of advices what to do avoid becoming a victim of these attacks are also given. In the end, information about artificial immunological systems are presented as one of the possible ways of modern security systems evolution.

Damian Kopeć

Nowoczesne metody bezpieczeństwa serwerów na przykładzie serwerów DNS

Damian Kopeć

Nowoczesne metody bezpieczeństwa serwerów na przykładzie serwerów DNS

10

11

---