Geneza Internetu - Notatki -  Informatyka - Część 4, Notatki'z Informatyka. Szczecin University of Technology
Norbert_88
Norbert_8827 lutego 2013

Geneza Internetu - Notatki - Informatyka - Część 4, Notatki'z Informatyka. Szczecin University of Technology

PDF (1 MB)
23 strony
688Liczba odwiedzin
Opis
Powstanie Internetu , definicja "Języka C", Unixa, historia i działanie TCP/IP, czym są i jak działają poszczególne protokoły, Firewall, SSH.
20 punkty
Punkty pobierania niezbędne do pobrania
tego dokumentu
Pobierz dokument
Podgląd3 strony / 23

To jest jedynie podgląd.

3 shown on 23 pages

Pobierz dokument

To jest jedynie podgląd.

3 shown on 23 pages

Pobierz dokument

To jest jedynie podgląd.

3 shown on 23 pages

Pobierz dokument

To jest jedynie podgląd.

3 shown on 23 pages

Pobierz dokument

1

Network Adress translation

Tłumaczenie adresów

Translacja adresów jest implementowana we większości firewalli i jest używana

wtedy, gdy nie chcemy, aby zdalny system poznał prawdziwe adresy IP w

wewnętrznej sieci. Są trzy sposoby translacji adresów:

 ukrywanie adresu sieciowego (ukrywanie NAT),

 statyczna translacja adresów sieciowych (staticzne 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 zupełnie innym poprawnym

adresem. Największym ograniczeniem tej metody jest brak możliwości połączenia

się z zewnątrz. Poniważ wszystkie komputery schowane są za jednym adresem IP,

firewall nie ma możliwości sprawdzenia, do którego z komputerów w wewnętrznej

sieci kierowane jest połączenie.

Statyczne NAT jest podobne do ukrywania NAT, z wyjątkiem tego, że każdy

lokalny adres IP jest ukryty za osobnym adresem. Pozwala to firewallowi na

rozpoznanie do którego komputera skierować połączenie. Wiekszość urządzeń NAT

pozwala na jednoczesne ukrywanie NAT i statyczne NAT. Pozwala to na

przydzielenie osobnych adresów tylko tym systemom, które tego potrzebują,

ukrywając inne.

Translacja PAT jest używana przez większość serwerów proxy. Cały ruch na

zewnątrz jest tłumaczony w taki sam sposób, jak ukrywanie NAT, lecz adresy

muszą być ukryte za adresem firewalla. Aby umożliwić ruch przychodzący z

zewnątrz, mapuje się porty do konkretnego systemu.

W celu precyzyjnego określenia praw rządzących dostępem do sieci tworzy się tak

zwane listy reguł. Listy takie opisują prawa poszczególnych obiektów do

korzystania z określonych usług/protokołów sieciowych, zezwalają na pewne

rodzaje połączeń z zewnątrz jednocześnie zabraniając innych, mogą limitować

docsity.com

2

liczbę połączeń z jakiegoś adresu albo ograniczać liczbę jednoczesnych połączeń.

Przykładowo, kierownictwo firmy może zabronić pracownikom w określonych

godzinach korzystania z usługi http z konkretnych miejsc sieci (co, oczywiście, jest

decyzją polityczną). Edytor reguł jest narzędziem, przy pomocy którego budujemy i

modyfikujemy zbiory reguł oraz wiążemy aplikacje z protokołami, a tym z kolei

przypisujemy interfejsy sieciowe. Na użytek zaawansowanych administratorów

tworzone są specjalne języki skryptowe, ułatwiające automatyzowanie

konfigurowania serwera.

Integralną częścią systemów firewall jest mechanizm o zbliżonej roli do "czarnej

skrzynki" w samolotach, śledzący i rejestrujący wszelkie wydarzenia w sieci. Dzięki

monitorowaniu uwadze administratora z pewnością nie umknie, na przykład, 30-

krotna nieudana próba zdalnego logowania się do systemu. Innym zastosowaniem

jest analiza adresów, z którymi najczęściej nawiązywane są połączenia przez

lokalnych użytkowników, gdyż dane takie są istotne do efektywnego

skonfigurowania serwera proxy. Jednocześnie zarządca ma wgląd w dziennik

błędów, gdzie zachowywane są ostrzeżenia o występowaniu wszelkich problemów z

poprawnością transmisji. W przypadkach, gdy zachodzi uzasadnione podejrzenie, iż

nastąpiło włamanie do sieci, system monitorujący może samodzielnie podjąć akcję

zdefiniowaną przez administratora, na przykład decyzję o zerwaniu połączenia albo

uruchomieniu "alarmu".

Powszechne konfiguracje firewalli

Sieć prywatna z tradycyjnym proxy - w tym wypadku pakiety pochodzące

z sieci prywatnej nie przechodzą do Internetu i na odwrót. Adres IP sieci

prywatnej powinien być przydzielony z jednej z trzech puli adresów:

10.*.*.*, 172.16.*.* lub 192.168.*.*. Jedynym sposobem na połączenie się z

Internetem jest połączenie się z firewallem, który jest jedyną maszyną

podłączoną do obu sieci na raz. Na firewallu uruchamia się program zwany

proxy (są proxy do FTP, usług WWW, telneta i wielu innych usług). Każda

usługa, która ma być udostępniona przez Internet musi być uruchomiona na

firewallu.

Aby umożliwić np. dostęp do stron WWW z sieci prywatnej należy

docsity.com

3

uruchomić na firewallu proxy WWW (np. squid), które będzie pracowało na

porcie np. 8080. Przeglądarka internetowa na komputerze użytkownika musi

być skonfigurowana do połączenia z serwerem proxy na firewallu na porcie

8080. Nie potrzebna wtedy jest konfiguracja innych parametrów, np.

domyślnej bramy sieci prywatnej.

Jeżeli użytkownik będzie chciał pobrać stronę z jakiegoś adresu,

przeglądarka połączy się z proxy WWW na firewallu i poprosi o tę strone.

Proxy łączy się wtedy na ten adres i pobiera stronę, a następnie przesyła ją do

przeglądarki użytkownika. Z punktu widzenia serwera WWW gdzieś w

Internecie, łączył się z nim firewall, a z punktu widzenia użytkownika, jego

komputer łączył się z firewallem i stamtąd pobierał dane.

Sieć prywatna z przeźroczystym proxy - podobnie jak wyżej, pakiety z

sieci prywatnej nie przechodzą do Internetu i na odwrót. Adres IP sieci

prywatnej powinien być z puli 10.*.*.*, 172.16.*.* lub 192.168.*.*. Aby

połączyć się z Internetem należy połączyć się z firewallem, który jest jedyną

maszyną podłączoną do obu sieci. Na firewallu uruchamia się program

zwany przeźroczystm proxy. Jądro wysyła wychodzące pakiety do

przeźroczystego proxy zamiast wysyłać je do drugiej sieci (pomija routing).

Używając przeźroczyste proxy nie musimy informować klientów, że takie

proxy w ogóle działa. Każda usługa, która ma być udostępniona przez

Internet musi być uruchomiona na firewallu.

Aby umożliwić np. dostęp do stron WWW z sieci prywatnej należy

uruchomić na firewallu przeźroczyste proxy WWW, które będzie pracowało

na porcie np. 8080. Jądro jest skonfigurowane, aby przekierowywać

połączenia na port 80 do proxy. Przeglądarka nie musi mieć żadnych

specjalnych ustawień. Na firewallu powinien stać serwer DNS jako proxy.

Domyślną bramą dla sieci prywatnej powinien być firewall.

Jeżeli użytkownik będzie chciał pobrać stronę z jakiegoś adresu,

przeglądarka otworzy połączenie z tym serwerem. W momencie, gdy pakiety

z komputera użytkownika przechodzą przez firewall, są przekierowywane do

przeźroczystego proxy. Proxy otwiera połączenie do serwera, z którego

pobiera stronę, a następnie przekazuje te dane do połączenia z przeglądarką

użytkownika. Z punktu widzenia serwera WWW łączył się z nim firewall. Z

docsity.com

4

punktu widzenia użytkownika, jego komputer połączył się z serwerem

WWW, ale tak naprawdę dane przesyłane były przez przeźroczyste proxy.

Sieć prywatna z maskaradą - w tym wypadku pakiety z sieci prywatnej nie

przechodzą do Internetu i na odwrót bez specjalnego potraktowania. Adres IP

sieci prywatnej powinien być taki, jak w poprzednich punktach. Zamiast

używać proxy, używa się specjalnej własności jądra systemu nazywanej

maskaradą. Maskarada przepisuje pakiety kiedy przechodzą przez firewall,

dlatego wydają się zawsze pochodzić z samego firewalla. Następnie

przepisuje także odpowiedzi tak, aby wyglądały że są wysyłane do

oryginalnego adresata. Maskarada ma specjalne moduły, które służą do

obsługi różnych protokołów, jak FTP, RealAudio, itp. Dla trudnych do

obsłużenia protokołów możliwe jest włączenie "auto-forwarding", który

może obsłużyć część z nich przez automatyczne ustawienie przekierowania

dla określonych zestawów portów. Każda usługa, która ma być udostępniona

przez Internet, musi być uruchomiona na firewallu.

Aby udostępnić np. dostęp do stron WWW z sieci prywatnej, firewall musi

mieć skonfigurowaną maskaradę dla dowolnych pakietów , które wychodzą z

sieci prywatnej i są kierowane na porty 80 serwerów internetowych.

Przeglądarka nie musi być w żaden specjalny sposób skonfigurowana.

Serwer DNS musi być skonfigurowany w sieci prywatnej. Domyślną bramą

dla sieci prywatnej powinien być firewall.

Jeżeli użytkownik będzie chciał pobrać stronę z jakiegoś adresu,

przeglądarka otworzy połączenie z tym serwerem. W momencie, gdy pakiety

z komputera użytkownika przechodzą przez firewall, są przepisywane tak

jakby nadchodziły z interfejsu PPP firewalla z określonego portu. Gdy serwer

WWW przesyła do firewalla dane na wcześniej określony port, dane te są

przepisywane i wysyłane do połączenia z przeglądarką użytkownika. Z

punktu widzenia serwera WWW łączył się z nim firewall. Z punktu widzenia

użytkownika, jego komputer połączył się z serwerem WWW (chociaż w

rzeczywistości połączenia dokonał firewall).

Sieć publiczna - tutaj sieć lokalna jest częścią Internetu i pakiety

przepływają bez zmian między sieciami. Pula adresów IP sieci prywatnej

musi być przydzielona przez złożenie podania o blok adresów IP. W tym

docsity.com

5

przypadku filtr pakietów jest używany do ograniczenia przekazywania

pakietów między siecią a resztą Internetu, np. przez ograniczenie, że ze

strony Internetu można połączyć sie tylko na serwery WWW w sieci

lokalnej.

Aby udostępnić np. dostęp do stron WWW z sieci lokalnej, firewall musi być

skonfigurowany do akceptacji całego ruchu. Przeglądarki internetowe nie

wymagają specjalnych konfiguracji. Serwer DNS musi być skonfigurowany

w sieci lokalnej. Domyślną bramą sieci lokalnej powinien być firewall.

Jeżeli użytkownik będzie chciał pobrać stronę z jakiegoś adresu, jego

przeglądarka połączy się z serwerem WWW. Pakiety przechodzą przez

firewall, tak jak przez inne routery. Połączenie jest tylko jedno - z komputera

użytkownika do serwera WWW.

Przekierowywanie portów - jest to sposób aby udostępnić Internetowi

usługi bez uruchamiania ich na firewallu. Będą one pracowały podobnie jak

proxy lub maskarada dla połączeń zewnętrznych. Sposobem na to jest

przekierowywanie (redirecting) portów. Firewall czeka na połączenie na

danym porcie i jeżeli takie przyjdzie, otwiera połączenie do zdefiniowanego

serwera w sieci lokalnej, który udostępnia daną usługę. Firewall kopiuje dane

między tymi połączeniami.

Z punktu widzenia Internetu połączenie odbywa się z firewallem, a serwer w

sieci lokalnej widzi to jako połączenie z firewallem.

Przekierowywanie portów może być może wykonywać specjalny program

(np. redir) lub przez ustawienie forwardingu w jądrze systemu.

Przykłady reguł dla IPChains

Aby blokować pakiety z określonym adresem IP należy wpisac:

# ipchains -A kierunek -j DENY -p all -l -s x.x.x.x/x -d 0.0.0.0/0

gdzie kierunek to: input, output lub forward. Input oznacza pakiety, które

przychodzą do systemu. Output to pakiety wychodzące do sieci. Forward oznacza

pakiety, które docierają do systemu, ale nie są kierowane do tej maszyny - pakiety te

są rutowane przez Linuxa. Input i output dotyczny także pakietów typu forward.

docsity.com

6

Do specyfikacji adresu IP źródła pakietu służy opcja -s, po której podajemy adres IP.

Można także podać grupę adresów przez podanie po znaku slash maski podsieci, lub

liczby bitów maski. Adres 0.0.0.0/0 (lub 0/0) oznacza dowolny adres IP. Podobnie

opcja -d oznacza docelowy adres IP pakietu.

Można także podać protokół, który chce się filtrować. Słyży do tego opcja -p. W

przykładzie powyżej blokujemy wszystkie protokoły. Poprawnymi wartościami są

tcp, udp, icmp lub all. Można także użyć protokołów z pliku /etc/protocols.

Powinno używać się opcji -l, aby umożliwić logowanie pakietów, które spełniają

podane zasady. Każdy taki pakiet będzie wpisany do logu jądra systemu.

Aby włączyć filtrowanie określonego portu należy wpisać:

# ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -d y.y.y.y/32 port

# ipchains -A input -j ACCEPT -p tcp -s x.x.x.x/24 -d y.y.y.y/32 port

gdzie y.y.y.y jest adresem IP maszyny, którą chcemy chronić, a x.x.x.x jest maską

podsieci, z której istnieje możliwość połącznia się na dany port. Zamiast numeru

portu można użyć także nazwy usługi z pliku /etc/services.

Aby zdefiniować zamiast pojedyńczego portu zakres portów nalezy podać np.:

# ipchains -A input -j DENY -p tcp -l -s x.x.x.x/x -d y.y.y.y/32 10:100

Wyboru typu i kodu pakietu ICMP można dokonać w podobny sposób jak wybór

numeru portu dla protokołów TCP lub UDP. Należy je podać jako dodatkowy

argument na końcu komendy.

Filtrowanie interfejsu sieciowego:

Wybór interfejsu sieciowego, który chcemy filtrować odbywa się za pomocą opcji -

i, np.:

# ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -i eth1 -d y.y.y.y/32 80

docsity.com

7

Aby Linux mógł być użyty jako router, należy umożliwić przekierowywanie IP

przez system. Słyży do tego komenda:

# echo "1" > /proc/sys/net/ipv4/ip_forward

Po reboocie systemu, zostanie przywrócona wartość 0, należy więc wpisać tę

komendę do skryptów inicjujących.

Wymagania sprzętowe

Każdy Firewall powinien posiadać co najmniej dwa adresy, więc wymagane będą

dwie karty sieciowe lub inne interfejsy transmisyjne (np. porty szeregowe, modemy

ISDN, karta sieciowa + modem). Jedno z urządzeń połączone jest ze strefą

zdemilitaryzowaną (DMZ) a drugie z siecią prywatną. Interfejsy należy dobrać tak,

aby nie zmniejszyć przepustowości łącza (np. w przypadku łącza FastEthernet

dobieramy dwie karty 100Mb). Jeśli zdecydujemy się na darmowy Firewall

działający pod Linuxem wystarczy komputer z 16MB RAM i 300MB partycją.

Proste zapory ogniowe działające pod Windows 95 lub Windows NT mają

wymaganie nie większe od systemu operacyjnego. Większe systemy komercyjne,

jak Novell BorderManager potrzebują min. 48MB RAM (+500 KB RAM dla

każdych 100 otwartych połączeń TCP przechodzących przez bamkę IP) i 250 MB

miejsca na dysku. W celu zapewnienia poprawnego działania Proxy Cache należy

zainstalować minimum 48 MB RAM i co najmniej dodatkowe 250 MB HDD w celu

efektywnego wykorzystania pamięci podręcznej. Warto zwrócić uwagę, że przy

dużej ilości połączeń obsługiwanych przez wszelkiego rodzaju Proxy Servers,

dodatkowa pamięć RAM przyspieszy pracę.

Kryteria wyboru

Jeżeli w naszym systemie są przechowywane dane, których zniszczenie bądź

ujawnienie wiązałoby się z poważnymi konsekwencjami, to taka podsieć powinna

docsity.com

8

być izolowana i nie mieć fizycznego połączenia z siecią globalną. Gdy jednak jest to

niemożliwe, należy zdecydować się na jeden z profesjonalnych systemów firewall.

Zanim dokonamy takiego wyboru warto rozważyć następujące kwestie:

 czy koszt inwestycji nie przekroczy wartości chronionych danych,

 tanie lub darmowe systemy charakteryzują się zwykle wysokim kosztem

instalacji, konserwacji, obsługi i administracji (np. oprogramowanie dla

Linuxa), więc być może opłaci się zainwestować na początku w droższy ale

łatwiejszy w eksploatacji produkt,

 jaki poziom zabezpieczeń, monitoringu, kontroli jest rzeczywiście potrzebny,

 jaki poziom ryzyka jesteśmy w stanie zaakceptować, jaki jest najbardziej

pesymistyczny scenariusz w przypadku wtargnięcia intruza,

 możliwości zdalnej konfiguracji i zarządzania systemem,

 jakie usługi dodatkowe są nam potrzebne (VPN, IPX/IP Gateway, NAT).

W trakcie instalacji należy rozwiązać kolejne problemy:

 czy użytkownicy Internetu będą wysyłać/przysyłać pliki do/z serwera firmy,

 czy firma będzie udostępniać stronę WWW i czy nie warto serwera WWW

wydzielić z zabezpieczanej sieci,

 odpowiedni podział pracowników na grupy o różnych prawach do

poszczególnych usług,

 optymalny podział sieci na podsieci i przyłączenie ich do odpowiednich

interfejsów.

Wady i zalety firewalli

Zalety:

 ochrona systemu,

 umożliwiają całej sieci korzystanie z jednego wspólnego adresu IP,

 dają możliwość na podłączenie do Internetu systemom z protokołami innymi

niż TCP/IP,

 pozwalają monitorować połączenia WAN i ruch w sieci,

docsity.com

9

 przy intensywnej pracy z WWW Proxy Cache Server pozwala

zoptymalizować obciążenie na łączu WAN, a co za tym idzie - przyspieszyć

pracę wielu osób,

 zamiast wynajmować drogie międzymiastowe lub międzynarodowe linie

dzierżawione możemy używać VPN i tańszych linii z dostępem do

najbliższych węzłów sieci publicznej.

Wady:

 ograniczają dostęp do sieci z Internetu,

 wymagają częstych uaktualnień, gdyż nowe typy klientów sieciowych i

serwerów przybywają prawie codziennie,

 uniemożliwiają bądź utrudniają zdalne zarządzanie siecią,

 mało wydajne serwery pośredniczące zmniejszają wydajność sieci.

1

SSH

Jedną z "fajniejszych" a przynajmniej wyrożniających rzeczy w UNIX-ie jest

możliwość zdalnej administracji.

Niestety narzędzia takie jak telnet, rsh nie są na tyle bezpieczne aby przy ich

pomocy móc administrowac swoim serwerem.

Telnet , usługa tak przydatna osobom potrzebującym zdalnego dostępu do własnych

kont ma jedną podstawową wadę. Otóż cala transmisja komend i danych włączając

w to wpisywane przez użytkownika login i haslo, przesyłana jest do celu otwartym

tekstem. Ponieważ raczej rzadko zdarza się, by połaczenie do zdalnej maszyny było

bezpośrednie, wszystko to idzie przez dzisiątki routerów i bramek co stwarza nie

jedną okazję do przechwycenia naszej transmisji.

1 Serwery sieciowe Linuksa:Jacek Sokulski, Wydanie MIKOM, Warszawa 2000, s.471 Unix Administracja Systemu: Eleen Frisch, s.640 Network Security:Krzysztof Kleszczyński, Wydawnictwo Informacji Zawodowej, Warszawa 2002, s.98 Security and Optimization Linux:Red Hat Edition- exclusively from OpenDocs, czerwiec 2000 ,s.284

docsity.com

10

. Dlatego też kilka lat temu znany fiński hacker Tatu Ylönen stworzył mądre

narzędzie powszechnie nazywane Bezpieczną Powłoką (Secure Shell) lub SSH.

Dlaczego mądre ?? Bo oprócz tego co umożliwiały tradycyjne programy do zdalnej

komunikacji, SSH pozostwiało użytkownikowi wybór czy chce kodowaną

transmisje danych czy nie .

Drugą zaletą SSH jest automatyczne logowanie. Możemy się dostać na konto w sieci

bez podawanie hasła.

Wygląda to jak rlogin ale mechanizm jest trochę inny. Identyfikacja odbywa się za

pomocą dwóch kluczy - prywatnego oraz publicznego, który jest umieszczany na

odległej maszynie. Kolejną zaletą jest to, że na życzenie użytkownika SSH potrafi

kompresować dane (wystarczy podac opcję -C). Dane wtedy są przesyłane przez

tak zwany tunel ssh. Jest to szczególnie pożyteczne przy pobieraniu plików

teskstowych (chodzi oczywiście o czas).

Innym zastosowaniem tunelów transmisyjnych SSH jest możliwość łączenia się z

serwerami irc-a. Dzięki temu możemy się pozbyć przykrych restrykcji takich jak +r.

SSH pozwala podobnie do telnetu, na zdalną pracę na konkretnej maszynie jednak w

przeciwieństwie od telnetu treść transmisji przez port SSH (22) jest praktycznie

niemożliwa do przechwycenia jakimkolwiek snifferem [-programem, który

monitoruje i rejestruje hasła oraz identyfikatory używane w trakcie logowania się

użytkowników.Często wykorzystywany jest przez snifferow tzw. koń trojański].

Wszystko dzięki temu, ze nasza sesja jest kodowana przy użyciu jednego ze znanych

algorytmów kryptograficznych opartych na metodzie kluczy kodujących i

dekodujących.

Te algorytmy to: IDEA, DES, 3DES, Blowfish i Arcfour.

Z tych 5-ciu algorytmów DES jest możliwy do złamania przez osoby mające do

dyspozycji maszyny o "niesamowitej" mocy obliczeniowej.

Pozostałe zwłaszcza IDEA oraz Blowfish [mój ulubiony ;)] są uważane za

całkowicie bezpieczne.

Jak to działa ? Każdy komputer w momencie instalacji musi wygenerować parę

docsity.com

11

kluczy. Jeden z nich będzie dostępny dla wszystkich (tzw. host key), drugi prywatny

musi być starannie ukrywany. Oprócz tego serwer ssh (sshd) generuje co jakiś czas

dodatkowe dwa klucze tak zwane server keys.

Szyfrowanie transmisji odbywa się z udziałem wymienionych kluczy a nasza

tożsamość sprawdzana jest za pomocą podania hasla lub poprzez trzeci klucz, nasz

prywatny, który możemy wygenerować przy pomocy polecenia ssh-keygen.

Ponadto pakietem SSH możemy zastąpic standardowe polecenia systemu takie

jak: rlogin, rsh, rcp poprzez ssh i scp.

Poza wymienionym juz sniffingiem SSH potrafi nas zabezpieczyć przed atakami

takimi jak IP spoofing i DNS spoofing. O ile istotą sniffingu bylo podszywanie się

pod innego uzytkownika o tyle spoofing polega na podszywaniu się pod inny

komputer. Cel pozostaje ten sam - oszukanie systemu zabezpieczeń i dostęp do

zasobów. Większość systemów umożliwia dostęp do sieci tylko komputerom o

określonym adresie IP.

Przypomnijmy sobie plik .rhosts, z którego korzystał rlogin. Były w nim właśnie

adresy naszych 'zaufanych' hostów.

Zasada działanie

Produkty z rodziny "F-Secure" wykorzystują protokół SSH, który zapewnia

mechanizm kodowania danych w warstwie transportowej protokołu sieciowego.

Protokół zapewnia autoryzację pomiędzy dwoma komputerami w sieci, autoryzację

pomiędzy użytkownikami, wraz z ochroną prywatnoci i integralnosci ich danych.

Program F-Secure SSH UNIX Server może być używany wraz z programem dla

Windows F-Secure SSH, dla Macintosh'a i Unix'a w celu zapewnienia ochrony dla

zdalnych połączeń dokonywanymi pomiędzy komputerami. Oprogramowanie dla

serwera pracującego pod Unix'em zawiera narzędzia do administracji systemu, które

dostarczono do ochrony przesyłania plików i backup'ów wykorzystując kodowanie

przy pomocy klucza publicznego.

docsity.com

12

Program F-Secure SSH Server pod Unix'a zapewnia bezpieczny proces logowania,

transfer plików, pracę pod X11, połączenia w protokole TCP/IP poprzez niepewne

sieci. Serwer czuwa nad autentycznoscią danych, automatycznie dokonuje

kodowania sesji i integruje ochronę dla wszystkich przesyłanych danych. Do tego

celu wykorzystuje się protokół RSA, służący do wymiany kluczy i sprawdzania

autentycznosci oraz symetryczne algorutmy, Blowfish lub 3DES do kodowania

transferu danych.

Administratorzy systemów mogą użyć dostarczonych do pakietu narzędzi

umożliwiających podmianę istniejących protokołów, takich jak RSH, RLOGIN,

RCP, RDIST i TELNET. Dzięki temu administratorzy mogą wszystkie zadania

kierować poprzez bezpieczne połączenia. Narzędzia pozwalają na wykonywanie

chronionych backup'ów za pomocą RSA bazującego na kodowaniu kluczem

publicznym.

Program F-Secure SSH client zapewnia bezpieczny proces logowania w niepewnej

sieci. Program ssh w pełni zastępuje protokół TELNET dodatkowo realizując

sprawdzanie autentycznosci, automatyczne kodowanie sesji i integrację metod

ochrony zdefioniowanych w protokole SSH. F-Secure SSH client zapewnia pełną

emulację terminala VT100 i ANSI colors.

F-Secure SSH client również dostarcza technologię " TCP/IP port forwarding

technology" przekierowywania niechronionych połączeń poprzez chroniony kanał.

Jest to realizowane poprzez utworzenie zastępczego serwera dla źródłowego portu

pracującego pod protokołem TCP/IP. Serwer ten, utworzony na lokalnej maszynie,

czeka na połączenie programu użytkownika do portu źródłowego. Następnie F-

Secure SSH przesyła żądanie i dane przez chroniony kanał do zdalnego systemu. F-

Secure SSH server na zdalnym systemie dokonuje finalnego połączenia do

własciwego hosta i portu. Wiele zdalnych usług, które wykorzystują protokół

TCP/IP może być chronionych, między innymi: aplikacje użytkowników client-

server, systemy baz danych, i usługi takie jak HTTP, TELNET, POP, SMTP. F-

Secure SSH zapewnia automatyczne przesyłanie danych w X11 Windowing System,

głównie używanych na maszynach unix'owych.

docsity.com

13

Zasada działania

Każdy z komputerów na których jest zainstalowany pakiet SSH posiada parę kluczy

- klucz prywatny, możliwy do odczytania jedynie przez administratora danego

komputera oraz przez demona sshd, obsługującego usługę SSH i klucz publiczny

dostępny dla wszystkich użytkowników sieci. Połączenie jest realizowane po stronie

klienta przez program ssh (F-Secure SSH client) , a po stronie serwera przez demona

sshd (F-Secure SSH Server). Kiedy klient łączy się z demonem (serwerem) jako

pierwsze dane otrzymuje klucz publiczny serwera. Klient porównuje ten klucz z

zachowanym w wewnętrznej bazie danych, z poprzednich połączeń (o ile wcześniej

łączył się z tym serwerem, jeżeli nie to go tylko zapamiętuje w bazie danych). W

przypadku stwierdzenia niezgodności kluczy połączenie jest zamykane. W

przeciwnym przypadku klient generuje losową liczbę 256 bitową. Liczbę tę szyfruje

przy pomocy swojego klucza prywatnego oraz klucz publicznego serwera i tak

zakodowaną przesyła do serwera. Serwer przy pomocy swojego klucza prywatnego i

klucz publicznego klienta rozkodowuje przesyłkę, czyli wygenerowaną przez klienta

losowo liczbę. Liczba ta stanowi klucz używany do kodowania podczas dalszej

komunikacji.

Po dokonaniu autoryzacji komputerów następuje autoryzacja użytkownika.

Najpierw sprawdza się istnienie klucza publicznego klienta w globalnej bazie

danych kluczy publicznych innych serwerów (plik /etc/ssh_known_hosts) lub w

indywidualnej bazie danego użytkownika (plik ~/.ssh/known_hosts). W przypadku

znalezienia tego klucza, demon zezwala na dokonanie autoryzacji na podstawie

plików /etc/hosts.equiv, /etc/shosts.equiv, ~/.rhosts lub ~/.shosts. Pliki

/etc/shosts.equiv i ~/.shosts stanowią odpowiedniki plików /etc/hosts.equiv oraz

~/.rhosts ale wyłącznie dla usługi ssh, a więc stanowią znacznie lepszą metodę

autoryzacji. W przypadku niepowodzenia autoryzacji, sprawdzana jest obecność

pliku ~/.ssh/authorized_keys zawierającego klucze publiczne danego użytkownika

wygenerowane na innych stacjach. Plik ten może sobie stworzyć każdy użytkownik

indywidualnie przy pomocy polecenia ssh-keygen na stacji klienta i poprzez

przesłanie go na serwer. Następnie serwer próbuje dokonać autoryzacji użytkownika

w sposób analogiczny do przeprowadzonej wcześniej autoryzacji komputerów, tzn.

wymiany z klientem zakodowanej informacji przy pomocy pary kluczy: klucz

docsity.com

14

publiczny użytkownika, klucz prywatny serwera i klucz prywatny użytkownika,

klucz publiczny serwera. W przypadku niepowodzenia tej metody, demon pyta się

użytkownika o jego hasło. Ponieważ transmisja jest kodowana, nie ma obawy o

podsłuchanie go przez niepowołaną osobę.

Pakiet można skompilować na większość platform Unixowych. Zawiera on pełną

dokumentację wraz z opisem działania, instalacji i konfiguracji. Dodatkową zaletą

pakietu jest możliwość skompilowania go wraz z biblioteką powstałą podczas

kompilacji pakietu TCP_WRAPPER i kontrolowania dostępu do usługi ssh, na

zasadach identycznych, jak do innych usług sieciowych poprzez pakiet

TCP_WRAPPER.

Instalacja i konfiguracja

Instalacja SSH pod Linuxem:

Do instalacji oprogramowania dostarczonego w formie źródłowej niezbędny jest

kompilator C, oraz podstawowe narzędzia dostarczane z większością systemów

unixowych.

1. Należy rozpakować archiwum

gzip -cd ssh-1.2.26.tar.gz | tar xvf -

2. Następnie należy uruchomić skrypt konfiguracyjny, który sprawdzi

środowisko kompilacji (dostępne narzędzia systemowe, ścieżki dostępu,

wersje i zawartość bibliotek systemowych) i przygotuje odpowiednie pliki

konfiguracyjne.

cd ssh-1.2.26

./configure

Wywołując skrypt configure z dodatkowymi opcjami można np. zmienić

miejsce instalacji plików konfiguracyjnych lub binariów SSH, jednak w

przeważającej większości przypadków ustawienia domyślne są poprawne, i

takie będą stosowane w przykładach.

docsity.com

15

3. Po skonfigurowaniu pakietu należy go skompilować i zainstalować.

make

a następnie, jako root

make install

W trakcie instalacji utworzone zostają następujące pliki:

o W katalogu /etc/ssh :

 ssh_config - plik konfiguracyjny klienta SSH

 ssh_host_key - klucz prywatny serwera SSH

 ssh_host_key.pub - klucz publiczny serwera SSH

 sshd_config - plik konfiguracyjny serwera SSH

o W katalogu /usr/local/bin :

 make-ssh-known-hosts - skrypt perlowy do generacji plików

/etc/ssh_known_hosts

 ssh-askpass - prosty program dla X-Window służący do

wczytywania haseł

 scp - secure copy - bezpieczny zamiennik dla komendy rcp

 ssh-add - program służący do wprowadzania kluczy

publicznych do agenta autentykacji.

 ssh-agent - agent autentykacyjny

 ssh-keygen - generator kluczy prywatnych i publicznych

 slogin - secure login - link do ssh

 ssh - secure shell - bezpieczny zamiennik rsh

o W katalogu /usr/local/sbin :

 sshd - serwer ssh

Dodatkowo do podkatalogów w hierarchii /usr/local/man zostaną zainstalowane

strony dokumentacji do poszczególnych komend plików konfiguracyjnych.

Konfiguracja serwera SSH:

Głównym elementem serwera SSH jest demon sshd. Zastępuje on dwa programy,

które znajdują się w większości dystrybucji: rlogin i rsh. Służy do prowadzenia

bezpiecznej (kodowanej) komunikacji pomiędzy dwoma komputerami w sieci.

docsity.com

16

Sshd odczytuje konfigurację z /etc/ssh/sshd_config (lub z pliku określonego w linii

poleceń, w opcji -t). Plik ten zawiera pary: klucz - wartość. Każda z nich jest

zapisana w jednej linii. Linie puste i zaczynające się od znaku '#' są traktowane jako

komentarz i są pomijane.

Opis pliku konfiguracyjnego serwera ssh1 - /etc/ssh/sshd_config:

# This is ssh server

systemwide configuration

file.

Port 22

domyślny port dla ssh to właśnie 22

ListenAddress 148.81.XXX.XXX

adres, gdzie jest zainstalowany serwer

(demon) sshd obsługujący

ssh1.Ustawienie jest istotne przy

systemach o kilku kartach sieciowych (na

przykład rutery lub bramki).

Najwygodniej ustawić wtedy adres IP tej

karty sieciowej, do której połączenia będą

częstsze lub do karty od strony sieci

zewnętrznej.

HostKey /etc/ssh_host_key

RandomSeed

/etc/ssh_random_seed

Położenie pliku z kluczem oraz

parametrem losowym

KeyRegenerationInterval 3600

Co pewien czas następuje odnowienie

klucza maszyny. Ten czas (w sekundach)

ustawia się właśnie za pomocą tej opcji.

Domyślnie - 1 godzina.

PermitRootLogin no Czy root może się zalogować zdalnie za

pomocą ssh. Patrz uwagi dalej.

IgnoreRhosts yes

IgnoreRootRhosts yes

RhostsAuthentication no

Ignorowanie plików .rhosts, które

wskazują "zaufane" maszyny, skąd

mógłby się zalogować użytkownik bez

docsity.com

17

RhostsRSAAuthentication no podawania hasła oraz zezwalanie na

autentykację za pomocą mechanizmu

rhosts.

PrintMotd yes Czy wypisywać komunikat powitania

(motd - najczęściej /etc/motd)

X11Forwarding yes

XAuthLocation

/usr/bin/X11/xauth

Czy przekazywać dane połączenia X11

(graficznego) i za pomocą którego

programu dokonywać autentykacji

użytkownika w środowisku graficznym

X-Windows

# {Allow,Deny}Users | Groups

DenyGroups student

Zezwolenie na logowanie się za pomocą

ssh. Patrz dalej.

# najbezpieczniejsza jest autentykacja

RSA (tylko) - a reszta no

RSAAuthentication yes

Wybór metody autentykacji. Włączyć

TYLKO RSA.

PasswordAuthentication yes

PermitEmptyPasswords no

IdleTimeout 30m

Autentykacja za pomocą haseł -

włączanie, zezwolenie na puste hasła oraz

czas rozłączania podczas oczekiwania na

podanie hasła (tutaj- 30 minut).

# AllowHosts *.our.com

friend.other.com

DenyHosts home.pl

*.algonet.se krakow.tpnet.pl

opole.tpnet.pl

Z których maszyn można się łączyć za

pomocą ssh. Patrz dalej.

CheckMail no Czy po zalogowaniu ma się odbywać

sprawdzanie poczty.

AllowTcpForwarding no

Przy takim ustawieniu nie jest możliwe

tunelowanie ftp, ale maszyna jest

bezpieczniejsza.

AccountExpireWarningDays 30 Powiadamianie o kończeniu się ważności

docsity.com

18

konta (dni)

PasswordExpireWarningDays 14 Powiadamianie o kończeniu się ważności

hasła (dni)

ForcedPasswdChange yes Wymuszanie zmiany już nieważnego

hasła

Konfiguracja klienta SSH:

Ogólnosystemowa konfiguracja klienta ssh znajduje się w pliku /etc/ssh/ssh_config,

zaś opcje konfiguracyjne sprawdzane są w następującej kolejności:

1. opcje podane w linii komend

2. plik konfiguracyjny użytkownika ($HOME.ssh/config)

3. plik ogólnosystemowy

Opis pliku konfiguracyjnego klienta ssh1 - /etc/ssh/ssh_config:

Hosts * Otwiera sekcję dotyczącą połączeń do

danego hosta - * oznacza wszystkie hosty

ForwardAgent yes

Określa, czy agent autentykacyjny ma

być przekazywany na kolejne systemy na

które następuje logowanie

ForwardX11 yes

Zezwala na automatyczne przekazywanie

połączeń X11 ponad szyfrowanym

kanałem SSH

RhostsAuthentication no

RhostsRSAAuthentication no

Zezwalanie na autentykację za pomocą

mechanizmu rhosts.

PasswordAuthentication yes Autentykacja za pomocą haseł

RSAAuthentication yes

TISAuthentication no

Wybór metody autentykacji (wybrać

tylko RSA)

PasswordPromptHost yes

PasswordPromptLogin yes Czy program ma pytać o hasła.

docsity.com

19

FallBackToRsh no

UseRsh no

Możliwość użycia rsh w przypadku

niepowodzenia połączenia za pomocą

ssh. Można włączać, ale administrator

zdalnej maszyny prawie na pewno to

wyłączył.

BatchMode no

Możliwość użycia ssh w trybie

wsadowym. Wyłączyć gdy nie jest

koniecznie potrzebne. Może się przydać

tylko w kilku przypadkach.

EscapeChar ~ Jaki znak powoduje wyjście z połączenia

(jak w telnecie ctrl+])

Cipher 3DES Algorytm stosowany do szyfrowania przy

połączeniu ze zdalną maszyną.

Compression yes

CompressionLevel 9

Kompresja - domyślnie jest włączona,

poziom - 6. Dziewięć jest najwyższym, 0

wyłącza.

IdentityFile ~/.ssh/identity Położenie i nazwa pliku identyfikacji

2

LINUX I WIRUSY

Wirusy komputerowe do niedawna były wyłącznie utrapieniem użytkowników

DOSa i wszelkich rodzajów MS Windows. W ciągu kilku lat od powstania

koncepcji samopowielającego się kodu infekującego inne programy powstało

ich kilka tysięcy.

Użytkownikom Unixów ten problem jest prawie całkowicie nieznany dzięki

rozbudowanemu systemowi kontroli dostępu do plików i pamięci, będącemu jednym

z podstawowych założeń tego systemu. Wirus napisany według tradycyjnej

DOSowej filozofii może co najwyżej zainfekować pliki do których miałby prawa 2 Budowanie zabezpieczeń sieci komputerowych:Mariusz Stawowski, Wydawnictwo Warszawa 1999, s.134 Dokumentacja systemu Linux Red Hat Edition Polityka bezpieczeństwa i ochrony informacji: Tadeusz Kifner,Wydawnictwo Helion,Gliwice 1999,s.78

docsity.com

20

zapisu - czyli praktycznie tylko te należące do użytkownika, który go uruchomił.

Kolejnym utrudnieniem dla potencjalnego autora wirusa jest ogromna różnorodność

platform sprzętowych na których działają Unixy oraz to, że duża część

oprogramowania jest rozpowszechniana w postaci kodu źródłowego.

WIRUSY CZY ROBAKI? Nieprzyjazne środowisko stworzyło konieczność wyprodukowania wirusa

działającego na zupełnie odmiennej zasadzie, niż jego DOSowi pobratymcy.

Najsłynniejszym przejawem działania Unixowego mikroba był przypadek "robaka"

(ang. worm) Roberta T. Morrisa, który w roku 1988 zainfekował kilka tysięcy

Sunów i VAXów w Stanach Zjednoczonych. "Robak" wykorzystywał wszystkie

możliwości, jakie daje połączenie komputerów w sieć. Przy użyciu dziur w

implementacjach usług finger, rexec i protokołu SMTP wirus kopiował swój kod

(część w języku C, część w pliku obiektowym) na kolejne maszyny, wykorzystując

ich zasoby do zgadywania haseł na przyszłych ofiarach. Na temat jego działania

napisano obszerne rozprawy, z których niektóre wymieniono na końcu artykułu. W

późniejszym okresie pojawiło się jeszcze kilka "robaków", jednak epidemie miały

znacznie mniejszy zakres.

BLISS

Na początku stycznia 1997 wydawało się, że historia znowu się powtórzyła. W

grupach dyskusyjnych poświęconych bezpieczeństwu Linuxa pojawiły się

alarmujące listy o nowym wirusie Bliss, napisanym specjalnie pod ten system.

Sprawa stała się na tyle głośna (a może dlatego stała się tak głośna?), że firma

McAfee opublikowała informację o pojawieniu się nowego, groźnego wirusa pod

Linuxa, który oczywiście jest usuwany przez oferowany przez nią program VirScan.

Tymczasem 7-go lutego na listę best-of-security napisał anonimowy autor wirusa

rozwiewając większość plotek, które do tej pory zdążyły narosnąć wokół Blissa. List

zaczynał się tak: "To jest wirus. Jeśli go uruchomisz, to masz sporą szansę na

zniszczenie swojego systemu". Ale reszta była znacznie mniej sensacyjna.

Obecnie istnieją dwie wersje Blissa - stara i nowa, załączona do wzmiankowanego

listu autora wirusa. Bliss jest programem napisanym w C, po skompilowaniu

docsity.com

21

mającym 17892 (stara wersja) lub 18604 (nowa wersja) bajtów długości. Kod

źródłowy nie został opublikowany. Wirus nie jest "robakiem" w sensie takim jak

program Morrisa, jest nawet bardziej koniem trojańskim niż wirusem. Nie wykracza

poza prawa dostępu do plików choć trzeba przyznać, że wykorzystuje je do końca.

Wyszukuje wszystkie pliki do których może pisać i infekuje je swoją kopią. Potrafi

także wykryć starszą wersję siebie i podmienić ją na aktualną. Próbuje także

przywrócić datę modyfikacji zainfekowanego pliku. Przerywa działanie gdy

zorientuje się, że jego działanie jest śledzone debuggerem lub programem strace.

Jedna z niewielu rzeczy, które upodabniają go do "robaków" to próba wykorzystania

niewłaściwie zabezpieczonej usługi rsh (zapisywalne pliki .rhosts i /etc/hosts.equiv)

do uzyskania cudzej tożsamości oraz być może przeniesienia się na inne maszyny.

Według firmy McAfee Bliss jest wirusem nadpisującym - tzn. bezpowrotnie

zastępuje początek infekowanego programu swoim kodem. W rzeczywistości

zarówno stara (opisana przez McAfee) jak i nowa wersja zachowuje oryginał.

Uruchomienie zainfekowanego programu nie może pozostać niezauważone,

ponieważ Bliss wyświetla szczegółowe informacje co w danej chwili robi.

Bliss poza plikami binarnymi próbuje infekować skrypty shella, jednak tak

zarażonych plików potrafi później poprawnie uruchomić. Potrafi je za to wyleczyć.

Charakterystyczną cechą Blissa jest zapisywanie ścieżek do wszystkich zarażonych

programów w pliku /tmp/.bliss. Na tej podstawie Bliss uruchomiony z opcją "--bliss-

uninfect-files-please" próbuje usunąć swoje kopie ze znajdujących się na liście

plików.

Jak widać trafna jest uwaga jednego z czytelników listy linux-security, że "Bliss

wygląda raczej na rezultat prac naukowych niż złośliwego wirusa". Nadal nie da się

napisać wirusa infekującego system Unixowy w sposób podobny jak DOS lub MS

Windows oczywiście pod warunkiem, że nie uruchomi go administrator.

Blissa nie należy jednak lekceważyć - jeśli w naszym systemie znajdują się jakieś

zapisywalne przez wszystkich pliki wykonywalne to mogą one zostać zarażone

przez zwykłego użytkownika. Późniejsze uruchomienie takiego pliku przez

administratora zaowocuje epidemią, która może rozprzestrzenić się na cały system.

docsity.com

22

Może to też być dodatkową motywacją do przestrzegania podstawowej zasady

bezpiecznej pracy na Unixie - korzystania z uprawnień administratora tylko wtedy,

gdy jest to naprawdę niezbędne.

PROFILAKTYKA Warto od razu sprawdzić swój system pod kątem obecności infekowalnych plików.

Administrator systemu może to zrobić za pomocą dwóch poleceń:

% find / -type f -perm -003 -exec ls -l {} \;;

% find /home -name ".[rs]hosts" -exe ls -l {} \; -exec

grep "+" {} \;;

Pierwsze z nich znajdzie pliki wykonywalne zapisywalne przez wszystkich i

wyświetli ich bliższe dane. Jeśli nie ma szczególnych powodów do zachowania

określonych atrybutów pliku, to należy ustawić standardowe:

% chmod 755 plik(czyli "-rwxr-xr-x")

Trzeba też pamiętać, że podobne zagrożenie mogą stanowić pliki zapisywalne przez

grupę (szukamy ich opcją "-perm -030"). Oczywiście, sprawa w tym wypadku jest

znacznie mniej oczywista - zależy kto należy do grupy.

Drugie z wymienionych poleceń znajdzie wszystkie pliki .rhosts oraz .shosts

zawierające znaki "+" i wyświetli ich zawartość. Stanowią one poważną dziurę w

bezpieczeństwie usług rsh i ssh, wykorzystywaną m.in. przez Blissa. Pliki takie

należy usunąć jeśli ich istnienie nie jest w jakiś sposób uzasadnione.

Można wreszcie skorzystać z któregoś z publicznie dostępnych skanerów - SATAN,

ISS, COPS lub Tiger. Wszystkie z nich, poza szukaniem konkretnych dziur w

konkretnych usługach, sprawdzają także atrybuty plików wykonywalnych.

LECZENIE

W razie infekcji najprostszym rozwiązaniem będzie skorzystanie z usług samego

wirusa - uruchomienie go z opcją "--bliss-uninfect-files-please". Warunkiem jest

istnienie pliku /tmp/.bliss, w którym znajdują się dane zarażonych plików. Może to

wyglądać tak:

% bliss --bliss-uninfect-files-please

bliss type 1 version 0.4.0 (00010004)

Compiled on Feb 5 1997 at 18:35:33

docsity.com

23

Written by electric eel.

Debugging is ON

using infection log: /tmp/.bliss

/tmp/bliss/autoconf, ver 10002, at Wed Feb 19 23:25:11

1997

disinfecting: /tmp/bliss/autoconf

file.virus_size=18604, x=4513

read 4513 bytes

successfully (i hope) disinfected /tmp/bliss/autoconf 3

3 Autor nieznany: Pierwszy profesjonalny podręcznik hakera, Wydawnictwo Robomatic, Wrocław 1998, s. 572

docsity.com

komentarze (0)

Brak komentarzy

Bądź autorem pierwszego komentarza!

To jest jedynie podgląd.

3 shown on 23 pages

Pobierz dokument