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.

image_pdf

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.

image_pdf

Domena Internetowa .in-adress.arpa

Oceń tę pracę

Programy komunikacyjne przesyłają dane w postaci pakietów TCP/IP (Transmission Control Protocol/Internet Protocol), które mogą zawierać jedynie adresy adres TCP/IP nadawcy. Jednak host – odbiorca chciałby znać także nazwę a nie tylko adres host’a – nadawcy. Potrzebny jest więc mechanizm ponownej translacji z adresu na pełną nazwę komputera (full domain name). Oczywiście można do tego użyć name server’a.

Do tego celu stworzono specjalną domenę w sieci Internet, nazwaną .in-adress.arpa, która spełnia wyżej wymienione założenie. Wszystkie sieci TCP/IP są ulokowane w tej domenie.

Przykład:

            Adres:                           149.156.96.9
            Reverse Name:             9.96.156.149.in-addr.arpa
            Nazwa komputera:         galaxy.uci.agh.edu.pl

 

Dzięki tej domenie możliwy jest mechanizm bezbłędnego mapowania (mapping) adresu Internetowego na nazwę host’a, jak również lokalizacji wszystkich gateways w danej sieci lokalnej podłączonej do Internetu.

image_pdf

Szyfrowane tunele

Oceń tę pracę

Szyfrowane tunele, nazywane także wirtualnymi sieciami prywatnymi pozwalają na bezpieczne połączenie za pomocą internetu dwóch fizycznie rozdzielonych sieci bez narażania danych na monitorowanie. Same szyfrowane tunele mogą być przedmiotem takich ataków, jak próby zmiany trasy, inicjacja fałszywego połączenia i inne nadużycia możliwe do popełnienia, gdy tunel jest już otwarty. Jednakże mechanizmy uwierzytelniania i usługi bezpieczeństwa, gdy są zaimplementowane jako nieodłączna część ściany ogniowej pozwalają zapobiec wykorzystaniu już otwartego kanału.

Otwarte kanały są niedostępne do wykorzystania przez hakerów tak długo, jak długo szyfrowanie jest bezpieczne. Ponieważ ściany ogniowe umieszcza się na granicach Internetu są one doskonałymi punktami końcowymi tunelu. W ten sposób sieci prywatne użytkownika mogą przesyłać ruch tak, jakby były dwiema podsieciami w tej samej domenie. Szyfrowane tunele pozwalają również użytkownikom adresować zdalne wewnętrzne hosty bezpośrednio za pomocą ich ukrytych adresów IP. Maskowanie IP i filtry pakietów nie pozwalają na to jeżeli próba połączenia pochodzi bezpośrednio z Internetu.

Protokół PPTP (Point-to-Point-tunneling) w systemie Windows NT zapewnia szyfrowany tunel za pomocą usług bezpieczeństwa serwera zdalnego dostępu RAS (Remote Access Server). Także większość dystrybucji Linuxa pozwala korzystać z szyfrowanych tuneli. Generalnie wszędzie tam, gdzie jest to możliwe należy raczej korzystać z linii dzierżawionych niż z szyfrowanych tuneli. Nie powinno się komunikować między np. oddziałami firmy  za pomocą Internetu bez użycia jakiejkolwiek metody szyfrowania. Niezaszyfrowane nagłówki pakietów zawierają cenne informacje o strukturach sieci wewnętrznej.

Szyfrowane tunele to technologia używana w sieciach komputerowych, która zapewnia bezpieczną transmisję danych pomiędzy dwoma punktami w sieci. Tunele szyfrowane pozwalają na tworzenie zaszyfrowanych połączeń, które chronią dane przed nieautoryzowanym dostępem, zapewniając prywatność i integralność przesyłanych informacji. Takie połączenia są szczególnie ważne w sytuacjach, gdzie dane muszą być przesyłane przez niezaufane lub publiczne sieci, jak Internet.

Technologia szyfrowanych tuneli jest szeroko wykorzystywana w wirtualnych sieciach prywatnych (VPN), które umożliwiają użytkownikom lub oddziałom firmowym bezpieczny dostęp do zasobów firmowych przez Internet. Kluczowym elementem szyfrowanych tuneli jest użycie protokółu tunelowania, który kapsułkuje dane w dodatkowej warstwie, aby zabezpieczyć je przed podglądem lub modyfikacją przez osoby trzecie. VPN jest jednym z najpopularniejszych zastosowań szyfrowanych tuneli, a w jego ramach stosuje się różne protokoły tunelowania, takie jak PPTP, L2TP, IPsec czy SSL/TLS.

Zasada działania szyfrowanych tuneli opiera się na utworzeniu zaszyfrowanego kanału pomiędzy dwoma urządzeniami (np. komputerem i serwerem). Wszystkie dane przesyłane przez ten kanał są szyfrowane przed wysłaniem i odszyfrowywane po dotarciu do celu. Szyfrowanie zapewnia ochronę danych przed podsłuchiwaniem przez nieautoryzowane osoby, nawet jeśli dane przesyłane są przez publiczną sieć. Dzięki temu użytkownicy mogą korzystać z zasobów sieciowych, takich jak pliki, aplikacje czy intranet, w sposób bezpieczny.

Zalety szyfrowanych tuneli obejmują nie tylko ochronę danych przed nieautoryzowanym dostępem, ale także poprawę integralności informacji. Dzięki szyfrowaniu, dane są zabezpieczone przed manipulacjami podczas transmisji. Szyfrowane tunele są szczególnie przydatne w przypadku pracy zdalnej, gdzie użytkownicy łączą się z firmową siecią z różnych lokalizacji i mogą korzystać z zasobów, takich jak wewnętrzne aplikacje czy bazy danych, bez obawy o ich bezpieczeństwo.

Wyzwania związane z szyfrowanymi tunelami obejmują zarządzanie kluczami szyfrującymi, co jest kluczowe dla utrzymania bezpieczeństwa. Ponadto, utworzenie szyfrowanego tunelu może wiązać się z dodatkowymi wymaganiami dotyczącymi wydajności, ponieważ proces szyfrowania i deszyfrowania danych może wprowadzać opóźnienia. Dodatkowo, wdrażanie szyfrowanych tuneli w większych sieciach może wymagać specjalistycznej konfiguracji, aby zapewnić odpowiednią skalowalność i bezpieczeństwo.

Szyfrowane tunele są niezwykle ważnym narzędziem w zapewnianiu bezpieczeństwa komunikacji w sieciach komputerowych. Dzięki nim użytkownicy mogą przesyłać dane w sposób bezpieczny, nawet jeśli korzystają z publicznych lub niezaufanych sieci.

image_pdf

Program skanujący SATAN

Oceń tę pracę

SATAN (Security Administrator Tool for Analyzing Networks) był jednym z pierwszych narzędzi służących do analizy bezpieczeństwa w sieci komputerowej, stworzonym przez Michaela J. Salta w latach 90. Jego głównym celem było pomaganie administratorom sieci w wykrywaniu potencjalnych luk w zabezpieczeniach systemów komputerowych. SATAN umożliwiał przeprowadzanie testów na podatności systemów operacyjnych, aplikacji oraz usług działających w sieci.

Program oferował funkcję skanowania portów, dzięki której administratorzy mogli identyfikować otwarte porty w urządzeniach sieciowych. W ten sposób mogli określić, które usługi były dostępne i potencjalnie podatne na ataki. Kolejną funkcjonalnością było wykrywanie usług. SATAN analizował urządzenia w sieci, identyfikując uruchomione usługi i sprawdzając ich wersje, co umożliwiało wykrywanie znanych luk w oprogramowaniu, które mogły zostać wykorzystane przez atakujących.

Narzędzie oferowało również możliwość analizy konfiguracji systemów, szczególnie systemów operacyjnych UNIX. SATAN sprawdzał, czy w konfiguracji systemów nie występują błędy, takie jak niewłaściwe uprawnienia do plików czy nieaktualne wersje oprogramowania. Dzięki temu administratorzy mogli wykrywać potencjalne zagrożenia, zanim zostaną one wykorzystane przez osoby niepowołane. Program posiadał także funkcje testowania podatności, które pozwalały na przeprowadzanie symulacji ataków w celu zidentyfikowania słabych punktów w systemie.

SATAN miał jednak swoje wady. Narzędzie nie było zabezpieczone przed nieautoryzowanym dostępem, co oznaczało, że mogło zostać wykorzystane przez osoby niepowołane do przeprowadzania skanowań sieciowych bez zgody właścicieli systemów. Z tego powodu program stał się kontrowersyjny, gdyż osoby o złych intencjach mogły go używać do przeprowadzania ataków. Mimo tych zagrożeń SATAN był jednym z pierwszych narzędzi, które zrewolucjonizowały sposób analizy bezpieczeństwa sieci komputerowych.

Z biegiem czasu SATAN został zastąpiony przez bardziej zaawansowane i bezpieczne narzędzia, takie jak Nmap czy Nessus, które oferowały bardziej precyzyjne i kompleksowe rozwiązania w zakresie analizy bezpieczeństwa. Mimo zakończenia jego rozwoju, SATAN pozostaje ważnym kamieniem milowym w historii narzędzi zabezpieczeń sieciowych, stanowiąc punkt wyjścia dla wielu późniejszych technologii.

Tabela 9. Satan

Typ   pogramy skanującego: Skaner portów TCP/IP
Autor: Dan Fermer i Weitse Venema
Język   programowania: C,   Perl
Wyjściowy   system operacyjny: Unix   (ogólnie)
Docelowy   system operacyjny: UNIX
Wymagania Unix,   Perl 5.001+, C, Pliki nagłówkowe IP, prawa administratora

Źródło własne

Program skanujący SATAN światło dzienne ujrzał w kwietniu 1995 roku i od razu spowodował duże zamieszanie w środowiskach ludzi zajmujących się bezpieczeństwem sieci.

Cieszył się on zainteresowaniem medialnym jak żaden inny program tego typu. SATAN był programem skanującym, który nie tylko sondował większość luk znanych już w systemach zabezpieczeń, ale także – jeśli odnalazł taką lukę – natychmiast przedstawiał szczegółowe wskazówki jak taką lukę wykorzystać i dla przeciwwagi jak ją wyeliminować. Ponadto, SATAN okazał się pierwszym programem skanującym, który zwracał efekty swej pracy w formacie przyjaznym dla użytkownika.

Program ten do interakcji z użytkownikiem wykorzystuje interfejs HTML z formularzami, w których wpisuje się serwery do skanowania, tabelami, w których zwraca wyniki oraz kontekstowymi opisami pojawiającymi się w momencie znalezienia luki. Jest to świetne narzędzie z dobrze napisanym kodem i dużymi możliwościami rozszerzania.

Autorzy programu SATAN są uznanymi ekspertami od bezpieczeństwa systemów. Program ten jest uznanym standardem na platformie UNIX-a, do sprawdzania serwerów lokalnych pod kątem luk w systemie zabezpieczeń. SATAN został zaprojektowany dla platformy UNIX, napisany w językach C i Perl, a zatem można go uruchomić pod kontrolą różnych odmian tego systemu operacyjnego. Specyficzny problem pojawia się w pracy SATAN-a pod Linux-em. W oryginalnej dystrybucji tego systemu występują pewne pliki, które zakłócają działanie SATAN-a.

Program SATAN skanuje odległe serwery w poszukiwaniu znanych luk w systemie zabezpieczeń – tj.:

  • Luk w serwerze FTPD oraz występowanie katalogów FTP zapisywalnych przez „wszystkich”
  • Lukw sieciowym systemie plików – NFS
  • Wad NIS
  • Luk RSH
  • Wad pakietu Sendmail Luk serwerem X Windows
image_pdf