Zapory sieciowe Firewall. Cel pracy

Oceń tę pracę

Niewielu internautów zdaje sobie sprawę, że beztroskie przeglądanie stron WWW niekiedy niesie ze sobą wiele niespodziewanych niebezpieczeństw. W gąszczu światowej pajęczyny można trafić na kogoś, kto dla pieniędzy, zaspokojenia swojej ciekawości albo po prostu dla sportu będzie próbować złamać najbardziej wyrafinowane systemy zabezpieczeń i zagrozić naszemu komputerowi, który podświadomie uważamy za twierdzę nie do zdobycia.

Podłączenie do sieci publicznej jest dwukierunkowe: pozwala użytkownikowi nie tylko odbierać, ale i dostarczać informacje, co może odbywać się bez jego wiedzy i pozwolenia. Pracując w sieci należy liczyć się chociażby z tak zwanymi atakami Denial of Service, których celem nie jest zdobycie jakichkolwiek informacji, lecz unieruchomienie lub chwilowe zablokowanie serwera bądź stacji.

Podstawową zasadą działania wszelkich systemów ochronnych jest: „To co nie jest jawnie dozwolone – jest zakazane”. Firewall (zapory ogniowe) są instalowane między sieciami w celu wymuszenia kontroli dostępu między nimi. Generalnie rzecz ujmując, firewalle zabezpieczają przed nieautoryzowanym dostępem z zewnątrz do sieci lokalnej. Niektóre nawet mogą całkowicie blokować ruch pakietów z zewnątrz – dopuszczając ewentualnie pakiety poczty elektronicznej – zezwalając jednakże na swobodne komunikowanie się użytkowników sieci ze światem zewnętrznym. Inną pożyteczną cechą firewalli jest możliwość wykorzystania ich do rejestrowania i śledzenia wszelkich przychodzących pakietów (auditing).

Stacje umieszczane w pierwszej linii obrony, określane również jako bastion host, są punktami przez które przechodzą wszystkie informacje do sieci lokalnej i na zewnątrz. Dzięki takiemu scentralizowaniu dróg dostępu do sieci w jednym komputerze można łatwo zarządzać systemem ochrony.

2. Cel pracy.

Celem pracy jest przedstawienie i omówienie wybranych zagadnień związanych z bezpieczeństwem sieci komputerowych i zastosowaniem w nich zapór firewall. W pracy zostały opisane szczegółowo sposoby konfiguracji systemu Linux tak, by spełniał podstawowe zadania i funkcje stawiane przed skuteczną zaporą ogniową a także poruszono najważniejsze zagadnienia związane z podłączeniem i instalacją w sieci Internet komputera pracującego pod kontrolą systemu Windows.

W sierpniu 1996 r. miało miejsce jedno z najbardziej znanych i upokarzających włamań dotyczące Departamentu Sprawiedliwości USA. Hakerom udało się podmienić stronę Web na elektroniczne graffiti składające się portretów Hitlera i golizny. We wrześniu tego roku, na liście „zdobytych” znalazły się strony Web Brytyjskiej Partii Konserwatywnej, Nation of Islam, Amerykańskiego Stowarzyszenia Psychoanalityków, Sił Powietrznych USA oraz Centralnej Agencji Wywiadowczej, której nazwę zmieniono na Central Stupidity Agency (Centralna Agencja Głupoty/Bezsensu)[1].

Ten przykład pokazuje jak bardzo na niebezpieczeństwo narażone są serwery, dane  i strony www publikowane w sieci internet . Ochrona systemów komputerowych, budowa i konfiguracja zapór sieciowych oraz innych systemów zabezpieczeń są tematami niezwykle złożonymi (aktualnymi), których nie sposób wyczerpać w jednej publikacji czy książce.


 

[1] rekonstrukcje włamań do Departamentu Obrony, CIA oraz U.S. Air Force: http:/www.260.com

Canonical Name Entry

5/5 - (1 vote)

Canonical Name (CNAME) to jeden z rekordów DNS, który pozwala przypisać alias do istniejącej domeny. Jego głównym zadaniem jest skierowanie zapytań o jedną nazwę domeny do innej, która jest uznawana za „kanoniczną”, czyli główną nazwę. Zamiast tworzyć osobny rekord dla każdego subdomeny, można użyć rekordu CNAME, aby wskazać, że dana subdomena ma wskazywać na inną, już istniejącą nazwę.

Rekord CNAME jest często wykorzystywany do tworzenia aliasów dla subdomen, co ułatwia zarządzanie nimi. Na przykład, jeśli masz główną stronę internetową dostępną pod domeną example.com, możesz utworzyć subdomenę www.example.com, która będzie aliasem wskazującym na tę samą stronę, bez potrzeby powielania danych w konfiguracji DNS. W takim przypadku rekord CNAME w pliku strefy DNS będzie wyglądał następująco:

www    IN CNAME example.com.

Dzięki temu każde zapytanie skierowane do www.example.com zostanie przekierowane do example.com.

Rekordy CNAME mogą być również używane do wskazywania na usługi zewnętrzne, takie jak serwery pocztowe czy usługi chmurowe. Na przykład, jeśli korzystasz z usługi hostingu poczty elektronicznej, możesz ustawić rekord CNAME, który będzie wskazywał na adres serwera pocztowego dostawcy usług. Dzięki temu możesz używać swojej domeny, np. mail.example.com, zamiast adresu serwera dostawcy.

Chociaż rekordy CNAME są bardzo przydatne, mają pewne ograniczenia. Przede wszystkim, nie mogą być używane dla samej domeny najwyższego poziomu (TLD), czyli nie możesz stworzyć rekordu CNAME dla example.com, wskazując na inną domenę. Ponadto, rekord CNAME nie może współistnieć z innymi rekordami dla tej samej subdomeny, co oznacza, że nie można jednocześnie mieć rekordu A i CNAME dla tej samej nazwy.

Rekordy CNAME są kluczowym narzędziem w zarządzaniu domenami, ponieważ upraszczają konfigurację DNS, umożliwiając łatwe przekierowywanie zapytań o jedną nazwę domeny na inną. Dzięki nim, zarządzanie aliasami i subdomenami staje się bardziej elastyczne i efektywne.

Wpis nazwy kanonicznej CNAME specyfikuje alias dla nazw kanonicznych. Przykładowo, nazwą kanoniczną (znana też jako pełna nazwa BIND’a) jest miami.cities.dec.com to dobrym aliasem mogłoby być miami lub mi.

Alias musi być unikalny, wszystkie inne wpisy muszą być powiązane z nazwami kanonicznymi, a nie z aliasami. Nie wolno tworzyć aliasów, których potem się używa w innych wpisach.

Start of Authority Entry (SOA)

Oceń tę pracę

Określa początek strefy. Nie może być więcej niż jeden wpis SOA dla jednej strefy.
Format wpisu SOA:

name ttl addr-class entry-type origin person sesrial# refresh retry expire min

Poszczególne pola oznaczają:

name

Tutaj umieszczana jest nazwa host’a, na którym umieszczone są dane bazy. Zwykle jest nim główny serwer.

person

To pole definiuje login name i adres mail’owy osoby odpowiedzialnej za prowadzenie BIND’a/Hesiod’a w domenie lokalnej.

serial#

Pole przeznaczone jest na numer wersji pliku bazowego. Osoba edytująca pliki konfiguracyjne (master files) dla całej strefy powinna zwiększać o jeden wartość tego pola za każdym razem, kiedy dokonywane są zmiany w plikach. Zmiana numeru seryjnego informuje serwery drugorzędne (secondary servers) o konieczności dokonania zmian w plikach (skopiowania nowej informacji z głównego serwera). Maksymalna wartość wynosi 232-1 „po przecinku” (kropce oddzielającej wartości całkowite od dziesiętnych).

Numer seryjny pozwala na rozstrzygnięcie, która z dwóch kopii plików bazowych jest późniejsza. Zwykle serial # zaczyna się jedynką (1) i jest zwiększany o jeden za każdą zmianą zawartości pliku. Zaleca się używanie liczb naturalnych.

W praktyce używa się formatu rokmiesiącdzieńzmiana czyli np. wpis mogłby wyglądać tak: 1996050401.

refresh

Pole wyznacza jak często (w sekundach) serwer drugorzędny ma sprawdzać serwer główny, czy nie zachodzi potrzeba uaktualnienia plików. Jeżeli Pliki na serwerze drugorzędnym są nieaktualne (o czym świadczy inny serial # ) dane są kopiowane z głównego serwera.

Minimalny okres odświeżania to 30 sekund. Jeśli pole refresh nie zwiera żadnej wartości, dane nie są uaktualnianie automatycznie.

retry

To pole specyfikuje jak długo (w sekundach) drugorzędny server (secondary BIND/Hesiod server) będzie próbował odświeżyć dane, po tym jak podczas sprawdzania nastąpił błąd odświeżania. (Jeżeli server próbuje odświeżyć zawartość plików i kończy się to błędem, próbuje znowu, tyle sekund później, ile zostało zdefiniowane w tym polu).

expire

To pole określa dolny limit (w sekundach) czasu, w którym serwer drugorzędny może utrzymywać dane w cach’u bez potrzeby ich uaktualniania, lub do czasu, w którym serwer główny stwierdzi potrzebę uaktualnienia.

min

Pole specyfikuje domyślny minimalny czas ttl w przypadku, gdy pole ttl pozostawiono pustym.

Przykład:

Przykładowy wpis pola SOA. Średniki oznaczają komentarze – pierwsza linia określa pola dla łatwiejszej orientacji.

; name ttl addr-class entry-type origin                 person 
@                     IN         SOA     utah.states.dec.com hes.utah.states.dec.com
                                                 ( 1                    ; sesrial
                                                 3600                 ; refresh - co godzinę
                                                 300                   ; retry co 5 minut
                                                 3600000            ; expire co 1000 godzin
                                                 86400 ) ; min - ttl wynosi 24 godziny

W powyższym przykładzie widać, że wartość ttl nie została zdefiniowana w polu ttl, co wskazuje na wyspecyfikowanie tej wartości w polu min.

Średniki pozwalają na zwiększenie czytelności zapisu i dodawanie komentarzy.

Filtry pakietów

Oceń tę pracę

Pierwszymi ścianami ogniowymi w internecie były filtry pakietów. Filtr porównuje pakiety protokołów sieciowych (takich jak IP) i transportowych (takich jak TCP) z regułami zawartymi w bazie danych, po to by dalej przekazać tylko te pakiety, które odpowiadają kryteriom określonym w regułach. Filtry można zaimplementować w routerze albo w serwerze obsługującym stos protokołów TCP/IP.

Filtry zaimplementowane wewnątrz routerów nie pozwalają podejrzanemu ruchowi na dostęp do chronionej sieci, podczas gdy moduły filtrów TCP.IP na serwerach zapobiegają głównie temu, aby dany komputer odpowiadał na podejrzany ruch, jednak pakiety nadal docierają do sieci i mogą być skierowane do dowolnego umieszczonego w niej komputera. Filtry na routerach chronią wszystkie komputery w sieci docelowej przed podejrzanym ruchem, dlatego też filtrowanie w stosie TCP.IP serwera (tak jak jest to realizowane w systemie Windows NT) powinno być stosowane jedynie jako dodatkowe zabezpieczenie w stosunku do filtrowania w routerach a nie zamiast niego.

Zasady działania typowego filtra:

– filtr pomija próby nawiązania połączenia przychodzącego z zewnątrz sieci, przepuszcza próby nawiązania połączenia przychodzącego z wewnątrz.

– Eliminacja pakietów TCP przeznaczonych do portów, które nie powinny być dostępne dla internetu (na przykład port sesji NetBios), filtr powinien przepuszczać pakiety, które powinny przechodzić przez filtr (na przykład SMTP). W większości filtrów można dokładnie określić serwer do którego dopuszczany jest określony ruch – na przykład ruch SMTP do portu 25 może być dopuszczany tylko dla adresu IP serwera pocztowego.

– Filtr powinien ograniczać dostęp w ruchu przychodzącym z zewnątrz do pewnych zakresów IP.

Mało skomplikowane filtry pakietów lub routery z funkcją filtrowania pakietów, które wymagają otwarcia portów powyżej 1023 dla kanałów zwrotnych nie są urządzeniami bezpiecznymi. Nie zapobiegają mianowicie ustanawianiu przez użytkowników wewnętrznych lub koni trojańskich usługi na stacji klientom na portach powyżej 1023 i nasłuchiwaniu prób uzyskania połączenia z zewnątrz. Bardziej złożone ściany (filtry z badaniem stanu i proxy zabezpieczające) otwierają te kanały jedynie dla serwerów do których połączenie zwrotne powstaje w wyniku żądania pochodzącego z wewnątrz strefy chronionej – i to te właśnie ściany powinny być stosowane zamiast prostych filtrów pakietów, które nie potrafią określić stanu połączenia. Złożone filtry korzystają z firmowych algorytmów do badania stanów wszystkich połączeń które przez nie przechodzą, szukając znaków sygnalizujących włamanie takich jak wybór trasy przez nadawcę (source routing), zmianę trasy na podstawie komunikatu ICMP, podszywanie się pod adres IP. Połączenia, które wskazują te cechy są odrzucane.

Klientom wewnętrznym zezwala się na tworzenie połączeń do hostów zewnętrznych zaś hostom zewnętrznym w zasadzie zabrania się prób inicjowania połączenia. Kiedy host wewnętrzny decyduje się zainicjować połączenie TCP, wysyła komunikat TCP pod adres IP i numer portu serwera publicznego (np. microsoft.com:80  w przypadku kiedy chce się połączyć z witryną Microsoft). W tym inicjującym komunikacie przekazuje hostowi zewnętrznemu swój adres IP oraz numer portu, na którym będzie nasłuchiwał odpowiedzi (np. localhost:2050). Zewnętrzny serwer przesyła dane z powrotem do portu podanego przez wewnętrznego klienta. Ponieważ ściana ogniowa przegląda cały ruch wymieniany między dwoma hostami wie, że połączenie było zainicjowane przez wewnętrzny host przyłączony do jego wewnętrznego interfejsu, wie także jaki jest jego adres IP oraz na jakim porcie spodziewa się on otrzymać ruch zwrotny. Ściana pamięta aby zezwolić hostowi o adresie podanym w komunikacje połączenia na ruch powrotny pod ten adres, ale tylko do określonego portu.

Kiedy hosty objęte połączeniem zamkną połączenie TCP, ściana ogniowa usuwa pozycję, która zezwala zdalnemu hostowi na ruch zwrotny do hosta wewnętrznego ze swojej tablicy stanów (w pamięci połączeń).

Filtrowanie nie rozwiązuje całkowicie problemu bezpieczeństwa w Internecie. Po pierwsze, adresy IP komputerów chronionych filtrem są obecne w ruchu wyjściowym, co czyni łatwe określenie typu i liczby hostów sieci wewnętrznej przyłączonej do internetu i skierowanie ataku na te adresy. Filtrowanie nie ukrywa tożsamości hostów wewnątrz obszaru chronionego filtrem. Ponadto filtry nie mogą sprawdzać wszystkich fragmentów datagramów IP w oparciu o protokoły wyższych warstw, nie mogą na przykład przeglądać nagłówków TCP, które istnieją tylko w pierwszym fragmencie. Kolejne fragmenty nie mają tej informacji i mogą być jedynie porównywane do reguł warstwy IP, które są zazwyczaj łagodniejsze przy przepuszczaniu ruchu przez filtr, pozwala to eksploatować błędy w warstwie IP komputerów docelowych i może pozwolić na połączenie z koniem trojańskim zainstalowanym wewnątrz sieci.

Resource Records

Oceń tę pracę

Nazwy domen zawarte w przekazywanych informacjach mają postać ciągu etykiet, z których każda jest reprezentowana prze dwa oktety – jeden określający długość pola etykiety, drugi zawierający właściwą nazwę etykiety.

Nazwa domeny identyfikuje węzeł. Każdy węzeł może zawierać zbiór informacji, może też być pusty. Zbiór informacji związany z konkretną nazwą składa się z pojedynczych rekordów zasobów (resource records – RRs). Kolejność RR w zbiorze nie ma znaczenia i nie musi być zapamiętywany przez name server’y, resolver’y, lub inne części DNS’u.

Składnia Resource Records

Format RR pozostaje niezmienny dla wszystkich zasobów. Składają się na niego takie elementy jak:

NAME

nazwa właściciela, to znaczy nazwa węzła, do którego się odnosI

TYPE

2 oktety zawierające jeden z kodów RR TYPE

CLASS

2 oktety zawierające jeden z kodów RR CLASS

TTL

liczba całkowita 32-bitowa, określająca czas w którym dane są przechowywane w cache’u (nie muszą być odświeżane i sprawdzane z oryginalną zawartością)

RDLENGTH

naturalna liczba 16-bitowa określająca długość oktetów w polu RDATA

RDATA

Zmiennej długości ciąg oktetów, opisujący informację źródłową. Format zależy od rodzaju TYPE i CLASS w rekordzie.

Najczęściej spotykane typy pól dla pozycji TYPE:

A

adres host’a

NS

autoryzowany name server

CNAME

nazwa kanoniczna dla aliasu

SOA

wskazuje początek strefy autoryzowanej

WKS

opis najbardziej znanych serwisów

PTR

wskaźnik nazwy domeny

HINFO

informacje o hoście

MX

wymiana poczty

TXT

ciąg tekstowy

Wartości pozycji CLASS:

IN

oznacza Internet

CS

już nie używany, tylko dla przykładu

CH

klasa systemu CHAOS

HS

Hesiod

RRs są reprezentowane fizycznie w postaci binarnej jako pakiety protokołu DNS i są zwykle zakodowane podczas przechowywania w name server’ach i resolver’ach.

Pojedynczy RR mieści się w jednej linii (choć możliwe jest zapisanie go w kilku, z użyciem nawiasów). Początek wiersza określa zawsze właściciela rekordu, choć często spotykane są puste pola dla poprawienia przejrzystości zapisu (puste pole owner oznacza, iż właściciel jest taki sam, jak w przypadku poprzedniego rekordu). Następne pola wypełnia się zgodnie ze standardową składnią opisaną powyżej.