Bezpieczeństwo w systemach komputerowych


Bezpieczeństwo w systemach komputerowych

Wykonał:

Tałanda Jarosław

Wstęp 4

1. Bezpieczeństwo fizyczne

2.1. Umieszczenie serwera i dostęp do niego

2.2. Topologia sieci

2.2.1. Topologia szyny

2.2.2. Topologia pierścienia

2.2.3.Topologia gwiazdy

2.3. Osprzęt sieciowy

2.4. Bezpieczeństwo stacji roboczych

2.5. Bezpieczeństwo związane z modemami

2.6. Identyfikatory i oznaczanie sprzętu

3.Instalacja Systemu

3.1. Podział dysku na partycje

3.2. Wybór usług sieciowych

3.3. Programy ładujące system

4.Bezpieczeństwo systemu

4.1. Użytkownicy

4.2. Niebezpieczne programy

4.3. Szkodliwe programy

4.3.1. Koń trojański

5.Bezpieczeństwo w sieci lokalnej

5.1. Węszyciel

5.2. Skaner

5.2.1. Skaner systemowy

5.2.2. Skaner sieciowy

5.3. Podszywanie

5.3.1. Podszywanie IP

5.3.2. Podszywanie ARP

5.3.3.Podszywanie DNS

6.Bezpieczeństwo przesyłanych danych

6.1. SSH i SCP

7.Ataki odmowy obsługi DoS

7.1. Ataki na urządzenia sieciowe

7.2. Ataki na usługi sieciowe

7.3. Ataki na aplikacje

8.Firewall'e i proxy serwery

8.1. Firewalle filtrujące

8.1.1. ipachains/ipfwadm

8.2. Serwery proxy

8.2.1. squid

8.2.2. SOCKS

8.3. TCP Wrappers

8.4. Przykłady innych 'ścian ogniowych'

9.Rejestrowanie i pliki dziennika

9.1. lastlog

9.2. last

9.3. xferlog

9.4. httpd

9.5. Komunikaty jądra systemu

9.6. Inne narzędzia rejestrujące:

10. Backup i odzyskiwanie danych 53

10.1. Prosta archiwizacja

10.2. Narzędzie archiwizujące: cpio

10.3. Planowanie archiwizacji: dump

10.4. Odtwarzanie archiwizacji wykonanych przez dump: restore:

10.5. Inne pakiety archiwizujące

Wstęp

Początkowo system UNIX miał zastosowanie tylko w specjalistycznych dziedzinach. Używano go głównie na uczelniach, w ośrodkach badawczych, wojskowych, firmach telekomunikacyjnych. Wówczas komputery nie były tak popularne jak dziś a dostęp do nich mieli tylko nieliczni. Szybki rozwój techniki dał ludziom dostęp do coraz mocniejszych
i nowocześniejszych komputerów przy jednoczesnym obniżeniu kosztów produkcji.

Obecnie prawie każdego stać na kilkakrotnie szybszą i wydajniejszą maszynę niż ta, na którą mogła sobie pozwolić duża firma 15 lat temu. Znaczny wzrost liczby posiadaczy komputerów - począwszy od ośrodków badawczych wyposażonych w supernowoczesne maszyny równoległe po użytkowników zwykłych pecetów - wymusił powstanie i szybki rozwój sieci komputerowych, które dają możliwość komunikacji między dwiema odległymi maszynami. Pojawienie się sieci oraz fakt, że z jednego komputera zwykle może korzystać wielu użytkowników pociągnęło za sobą pojawienie się problemu ochrony tak samych komputerów jak i danych przez nie przechowywanych.

Generalnie problem bezpieczeństwa w systemach komputerowych można podzielić na dwa główne aspekty: problem bezpieczeństwa fizycznego i problem systemu wraz
z oprogramowaniem.

Należy zwrócić uwagę na to, że oba te problemy są równie istotne, choć tak w literaturze jak
i praktyce często problem bezpieczeństwa fizycznego jest pomijany.

1. Bezpieczeństwo fizyczne.

Zabezpieczenie fizyczne komputera (czy też serwera) jest istotnym elementem polityki ochrony całego systemu. Źle zabezpieczony system informatyczny można zniszczyć wysyłając exploita z sieci, ale używając młotka bezpośrednio na sprzęcie można poczynić
o wiele większe szkody. Mimo tego, że wiele zagadnień związanych z fizyczną ochroną sprzętu wydaje się oczywistych, użytkownicy notorycznie popełniają wiele prostych błędów.

    1. Umieszczenie serwera i dostęp do niego.

Bardzo ważny jest wybór miejsca umieszczenia serwera oraz ograniczenie liczby osób, które mają do niego fizyczny dostęp. Bardzo dobrym tego rozwiązaniem jest umieszczenie maszyny w oddzielnym pomieszczeniu potocznie nazywanym serwerownią, do którego dostęp mają tylko niektóre osoby. Oczywistym jest, że jeśli niepowołane osoby mają z komputerem styczność, nie da się zapewnić choćby minimalnego stopnia bezpieczeństwa. Czymże, bowiem jest zabezpieczenie systemu w postaci kontroli hasłem przy starcie, kiedy każdy może przy pomocy swoich dyskietek startowych uruchomić go w dowolnym trybie.

Umieszczony w oddzielnym pokoju komputer wraz z istotnymi peryferiami łatwiej zabezpieczyć (np. przykręcić do stołu). I nawet ci posiadający odpowiednie uprawnienia powinni podlegać jakiejś autoryzacji - na przykład przy pomocy kart magnetycznych.

Poza tym warto też mieć na uwadze następujące zagadnienia:

1.2 Topologia sieci.

Topologia sieci ma dość istotne znaczenie w kwestii bezpieczeństwa sieci. Odpowiedni dobór może utrudnić potencjalnemu włamywaczowi jej unieruchomienie. Istnieje wiele standardów topologii sieci, ale w sieciach lokalnych są stosowane głównie trzy: szyna, pierścień oraz gwiazda.

      1. Topologia szyny.

W tej topologii pojedyncze łącze (zazwyczaj kabel koncentryczny) obsługuje wszystkie urządzenia sieciowe. Taka sieć jest zupełnie nie odporna na uszkodzenia kabla - jakiekolwiek uszkodzenie medium lub nawet jednej z kart sieciowych użytkowników powoduje unieruchomienie całej sieci.

Dodatkową wadą tego typu sieci jest ograniczenie, które spowodowane jest tym, że w danej chwili szyna pozwala na przeprowadzenie tylko jednej transmisji. Ponadto każda stacja robocza jest w stanie przechwycić transmisję do któregoś ze swoich sąsiadów.

Zaletą sieci o takiej topologii są: prostota w budowie i niskie koszty wykonania.

      1. Topologia pierścienia.

W topologii pierścienia także istnieje pojedyncze medium transmisyjne, do którego podłączone są wszystkie urządzenia. Podobnie jak szyna, topologia pierścienia zawiera dwa podstawowe miejsca wystąpienia potencjalnej awarii unieruchamiającej całą sieć: dowolna stacja robocza (w tym również serwer) i kabel. Wszystkie urządzenia w sieci o topologii pierścienia służą za repeatery, więc uszkodzenie któregokolwiek z nich powoduje wspomnianą awarię sieci.

Dodatkowym zagrożeniem jest łatwość przechwycenia transmisji na dowolnym komputerze. Łatwość ta spowodowana jest tym, że istnieje duże prawdopodobieństwo, iż przez dowolny host przechodzić będzie transmisja odbywająca się między dwoma innymi dowolnymi komputerami w pierścieniu.

      1. Topologia gwiazdy.

Sieć zbudowana w topologii gwiazdy jest scentralizowana i tym samym dużo lepsza od szyny czy pierścienia. Wszystkie stacje robocze w danym (być może niewielkim) segmencie są podłączone do jednego urządzenia, co pozwala zarządzać połączeniem każdego komputera z osobna. Sieć o topologii gwiazdy bez problemu przetrwa także uszkodzenie kilku stacji roboczych. Dodatkowo istnieje możliwość podzielenia sieci na segmenty
i izolowania transmisji do poszczególnych komputerów (np. za pomocą routera czy switch'a).

Topologia gwiazdy ma jednak pewne wady. Centralizacja wymusza istnienie krytycznego punktu, którego awaria ma bardzo złe skutki. Jeśli atakujący wyłączy na przykład koncentrator, może odciąć od reszty sieci cały segment.

Podczas wybierania odpowiedniej topologii, należy mieć na uwadze następujące zagadnienia:

Topologia gwiazdy wydaje się być najlepszym rozwiązaniem. Jeśli jej zastosowanie nie jest

możliwe należy:

    1. Osprzęt sieciowy.

Wszelkie peryferia sieciowe, jak routery, koncentratory, itp. również muszą być odpowiednio zabezpieczone. Ataki na sprzęt są dużo groźniejsze niż na oprogramowanie.
O ile awaria pojedynczego komputera może nie być zauważona przez resztę sieci, awaria rutera może w całości ją unieruchomić.

Zazwyczaj udane ataki na sprzęt sieciowy wynikają z prostych błędów wynikających
z zaniedbania administratorów. Wielu z nich zapomina o włączenia kodowania podczas konfiguracji zdalnej albo o zmianie domyślnych haseł. Defaultowe hasła urządzeń sieciowych to podstawowa ściągawka hakera. Oprócz zmiany hasła należy, podobnie jak serwer, odizolować rutery od ogólnego dostępu. Duża część z nich pozwala na ominięcie hasła
w przypadku dostępu fizycznego (choćby przycisk resetujący NVRAM).

1.4 Bezpieczeństwo stacji roboczych.

Przy bezpieczeństwie stacji roboczych ważna jest kontrola dostępu i zabezpieczenie przed kradzieżą. Kontrola dostępu może być wspomagana poprzez hasła BIOS'u i konsoli. Hasła BIOS'u ograniczają możliwość zmiany ustawień komputera, a hasła konsoli zabezpieczają tryb jednoużytkownikowy. Zabezpieczenie BIOS'u hasłem jest tylko minimalną przeszkodą, ponieważ atakujący może jest ominąć wyjmując baterię z płyty głównej lub (w większości nowoczesnych płyt) ustawić odpowiednią zworkę powodując wyczyszczenie pamięci CMOS. Poza tym czasami działają standardowe hasła BIOS'u: BIOS, bios, biosstar, CMOS, cmos, condo, djonet, SETUP i setup oraz kombinacje klawiszy: F1, F3, CTRL+F1, CTRL+F3, STRL+SHIFT+ESC, DEL, CTRL+ALT+INS i CTRL+ALT+S. Do znalezienia hasła BIOS'u można użyć także jednego z narzędzi do manipulacji BIOS'em, np.: M!BIOS, AMIDECOD, AMI Password Viewer, AW.COM.

Nieco inną strategią jest użycie urządzeń kontrolujących dostęp według biologicznej charakterystyki użytkownika, czyli:

Zabezpieczenia tego rodzaju są bardzo wiarygodne, ale posiadają jedno podstawowe ograniczenie: nie można ich w żaden sposób zastosować do autoryzacji zdalnego użytkownika.

Należy też w takim przypadku pamiętać o ochronie danych osobowych i prywatności. Dowiedziono, że obraz siatkówki zawiera wiele danych o zdrowiu człowieka - mogą w nim być zapisane nawet ślady zażywania narkotyków lub AIDS.

Przykłady urządzeń biometrycznych (używanych nie koniecznie do autoryzacji):

1.5 Bezpieczeństwo związane z modemami.

Obecność modemów często obniża bezpieczeństwo sieci lokalnej, zwłaszcza, jeśli pozwalają na wdzwanianie do systemu. Jeśli sieć jest nie wielka, to wiadomo, kto korzysta
z modemu i łatwiej je kontrolować. Jeśli modemy są niezbędne w do pracy warto rozważyć możliwość utworzenia osobnej sieci do pracy z modemami lub wyznaczyć kilka stacji do tego celu, które zostaną odcięte od sieci lokalnej.

    1. Identyfikatory i oznaczanie sprzętu.

Należy także podjąć działania pozwalające zidentyfikować sprzęt po jego kradzieży.
Co roku giną dziesiątki tysięcy komputerów a większość ich użytkowników nie zapisuje nawet numerów seryjnych komponentów. Oprócz dokładnej inwentaryzacji sprzętu warto posłużyć się dodatkowo technikami pozwalającymi zidentyfikować sprzęt bez rozkręcania obudowy, np. poprzez oznaczenia niezmywalną farbą, farbą fluoroscencyjną czy reagującą na ultrafiolet.

Istotnym przy tym jest, że pewne 'zalety' sprzętu mogą naruszyć naszą prywatność. Teoretycznie nieodczytywalny bez zgody posiadacza numer seryjny procesora Intel Pentium III, który pozwala na zdalna identyfikację, w kilka tygodni po jego ukazaniu się na rynku został zdalnie odczytany przez niemieckich hakerów (mimo wyłączonej opcji jego udostępniania).

Więcej:

2. Instalacja Systemu.

Aby ochrona działającego systemu i sieci była skuteczna, niezwykle istotnym jest rozpocząć działania zabezpieczające już podczas instalacji systemu. Najważniejsze punkty instalacji systemu to:

2.1 Podział dysku na partycje.

Podział dysku na partycje ma na celu przede wszystkim zwiększenie kontroli położenia danych i zmniejszenie ryzyka związanego z utratą danych w przypadku uszkodzenia jednej z partycji.

Podział dysku na partycje ułatwia utrzymanie na nim porządku: można oddzielić pliki wymiany od pozostałych plików. Podział na partycje oczywiście umożliwia również posiadanie wielu systemów operacyjnych na jednym nośniku. System typu Unix posiad szerokie możliwości korzystania z partycji innych typów niż typ jemu dedykowany (np. HPFS, DOS/WINDOWS16/32, Novell NetWare, Minix, itp. - łącznie około ponad 80 typów). Listę typów obsługiwanych przez Linuxa możemy oglądnąć w programie cfdisk, opcja Type. Takich możliwości z pewnością nie udostępniają systemy Windows i podobne.

Nigdy nie powinno się umieszczać katalogu głównego i katalogów użytkowników na tej samej partycji. Takie rozwiązanie zwiększa szansę na wykorzystanie przez intruza programów typu SUID i kontroli nad krytycznymi zasobami systemu (o programach typu SUID mowa będzie w dalszej części niniejszego opracowania). Katalogi (a w zasadzie partycje, na których te katalogi się znajdują) z głównego drzewa, które w szczególności nie powinny mieć możliwości uruchamiania programów z bitem SUID (zwłaszcza, gdy ich właścicielem jest root): /home, /tmp, /var i wszystkie montowane urządzenia w /mnt. Jeśli rozmieszczamy w mniej standardowy sposób aplikacje w systemie, to sytuacja może wyglądać nieco inaczej, ale w ogólności należy pamiętać, by montować te partycje z opcją "nosuid", do których będą mieli dostęp zdalni (zwłaszcza poprzez anonymous FTP) i lokalni użytkownicy, mający niezbyt czyste zamiary wobec naszego systemu.

Określenie włączenia bądź wyłączenia tej możliwości na określone partycje znajdziemy
w /etc/fstab jako opcja "suid" i "nosuid".

Oprócz ochrony przed atakami na programy typu SUID, podział na partycje jest dobrym antidotum na zapychanie dysku przez logi systemowe i użytkowników. Jeśli zapomnieliśmy włączyć rotację logów znajdujących się zwykle w /var/log/messages lub poczta przychodząca zapchała /var/spool/mail, to w przypadku systemu, gdzie wszystko znajduje się na jednej partycji może dojść do jego unieruchomienia. A tak - po prostu logi się nie będą zapisywały i poczta nie będzie przyjmowana - to jeszcze nie jest wielka tragedia zwłaszcza w sytuacji, gdy nie jesteśmy w stanie szybko zareagować.

2.2 Wybór usług sieciowych.

Wybór usług sieciowych już podczas instalacji systemu pozwala nie tylko na oszczędzenie miejsca na dysku, ale wymusza zwiększenie uwagi u administratora na to co rzeczywiście jest niezbędne, a co jest nie potrzebne. Zwykle na rzeczy w systemie nie używane opiekun serwera nie zwraca uwagi, a co za tym idzie bagatelizuje problemy związane ze zmniejszeniem bezpieczeństwa systemu wywołane uruchamianiem nie potrzebnych usług. Na przykład jeśli dany komputer ma służyć jako serwer proxy, http, pocztowy i powiedzmy serwer samba, to warto się zastanowić czy pozostałe usługi będą nam rzeczywiście potrzebne. Jeśli użytkownicy to grupa osób głównie potrzebujących tych podstawowych usług a my sami innych nie zamierzamy używać, to lepiej w ogóle nie instalować takich rzeczy jak np. bootpd czy DHCPd, sound, nfs, lpd, ldap i wiele innych.
Z pewnością taki komputer nie będzie potrzebował systemu graficznego X-Window, który nie tylko zżera ogromne ilości zasobów, ale posiada dużą ilość 'dziurawych' aplikacji.

2.3 Programy ładujące system.

Zwykle podczas instalacji systemu, pod koniec tego procesu, określić należy sposób uruchamiania systemu. Do wyboru mamy różne programy, a dla systemu Linux najpopularniejszym jest LILO (Linux Loader). Zwykle w takich programach (programy te nazywa się 'boot managerami') określamy z jakiej partycji jaki system i w jaki sposób jest uruchamiany. Podczas konfigurowania takiego programu (zwykle już po zainstalowaniu
i zresetowaniu komputera) możemy ustawić hasło ładowania w pliku konfiguracyjnym (dla LiLo jest on /etc/lilo.conf - należy pamiętać o odpowiednich prawach dla pliku: 600). Takie podejście ma jednak pewną wadę. Jeśli atakujący dostanie się do możliwości modyfikowania ustawień BIOS'u to uruchomi system z własnych dyskietek, albo przynajmniej dostanie się do pliku konfigurującego boot manager'a.

3. Bezpieczeństwo systemu.

W przeciągu kilku ostatnich lat można było dużo usłyszeć o różnego rodzaju wykroczeniach związanych z systemami komputerowymi. Wiele gazet pisało o spektakularnych włamaniach do różnego typu systemów i spowodowanych tymi działaniami szkodach. Owszem szkody często bywają dotkliwe - zwłaszcza te, kiedy informacje z systemu wyciekają. Niemniej jednak duża część społeczeństwa uważa administratorów za ludzi o nadprzyrodzonych zdolnościach, którzy po nocach tropią elektronicznych przestępców wykorzystując swoją ponadprzeciętną inteligencję. Jak to na filmach można czasem zobaczyć, często miedzy strażnikami systemu i hakerami dochodzi do mniej lub bardziej 'krwawych' potyczek, pełnych laserów i migających świateł, w których przegrany ginie wchłonięty do nicości ...

W rzeczywistości praca administratora to nieco mniej barwne zadania. W zakresie bezpieczeństwa systemu najważniejsze z nich to:

3.1 Użytkownicy.

Rozpatrując kwestię dostępu użytkowników do systemu administrator zwykle zaczyna od siebie. Może zdziwić fakt, że dużą część funkcji administracyjnych nie wykonuje się
z konta root. Należy pamiętać, że operator z wszystkimi uprawnieniami root'a ma nieograniczoną władzę nad systemem co jest niebezpieczne w różnych okolicznościach. Łatwo jest np. skasować coś, chcąc usunąć całą zawartość tylko katalogu /tmp pisząc:

rm -fr / tmp

usuniemy całe drzewo katalogów wraz z podkatalogami - po prostu cały system. Tak więc ważne jest by (jeśli nie ma istotnej potrzeby) nie korzystać z konta z którego 'wszystko' można. Tak więc dobrze jest utworzyć osobne konto dodając mu część uprawnień administracyjnych. Do poszerzania zakresu możliwości określonego użytkownika możemy wykorzystać program sudo.

Najogólniej rzecz biorąc przydzielanie komuś konta oznacza upoważnienie go do:

Danie komuś możliwości logowania się w systemie powinno być zawsze starannie przemyślane. Jeśli administrujemy systemem, który ma służyć jako np. serwer pocztowy należy się zastanowić czy uzasadnione jest danie użytkownikom możliwości logowania się
w systemie. Jeśli danej organizacji musi być maszyna, do której musi być dostęp do powłoki, to warto się zastanowić nad wydzieleniem osobnego komputera, na którym:

Jeśli nie mamy takiej możliwości to trzymamy się po prostu zasady, że dostęp do powłoki otrzymują tylko Ci użytkownicy, którzy na prawdę tego potrzebują.

Informacje na temat zarejestrowanych użytkowników system przechowuje w pliku /etc/passwd. Jego budowa jest bardzo prosta, każda linia odpowiada jednemu użytkownikowi i najczęściej składa się z 7 pól oddzielonych dwukropkiem, np:

kaczor:x:501:501:Jaś Fasola:/home/kaczor:/bin/bash

Jego budowa jest bardzo prosta, a znaczenie poszczególnych pól nie jest tu szczególnie istotne. Najważniejsze z punktu widzenia bezpieczeństwa jest tylko pole drugie. W naszym przykładzie jest tam wartość 'x'. W starszych systemach oraz w systemach bez systemu maskowania haseł (tzw. shadowing) w miejscu tym znajduje się zaszyfrowane hasło użytkownika. A ponieważ plik /etc/passwd musi być dostępny do odczytu wszystkim użytkownikom posiadającym dostęp do powłoki systemu, więc w przypadku, gdyby znajdowało się tam hasło, system jest narażony na atak. W systemach posiadających pakiet shadow hasła użytkowników znajdują się w pliku /etc/shadow, który jest nie dostępny do odczytu zwykłym użytkownikom (właścicielem jest root:root a atrybuty pliku to 400).

W systemie UNIX autoryzacja polega na zaszyfrowaniu hasła podanego przez użytkownika i porównaniu z tym zapisanym w pliku shadow. Hasła są szyfrowane przy pomocy opracowanego przez IBM zaawansowanego algorytmu szyfrującego DES. Mimo,
że wykorzystywany jest dopiero od około 25 lat, standard DES (Data Encryption Standard) jest najpopularniejszym szyfrem w historii kryptografii. Zarówno szyfrowanie jak
i deszyfracja opierają się na kluczu, bez którego nie można odszyfrować zakodowanych informacji. Klucz ten (oparty na haśle użytkownika oraz pewnych dodatkowych danych, ang. padding) składa się z 64 cyfr dwójkowych. Do kodowania danych wykorzystuje się 56 bitów, pozostałe 8 bitów służy do kontroli błędów. Ilość wszystkich kluczy jest zatem dość duża: ponad 70 * 10^15 kluczy 56-bitowych. Algorytm DES jest szyfrem blokowym - operuje na blokach danych określonej długości (w tym przypadku są to 64-bitowe bloki). Dłuższe dane dzielone są na fragmenty 64-bitowe. Mniejsze porcje wypełniane są nieistotnymi bitami tak, by zawsze blok miał długość 64 bitów.

Do pełnego zakodowania hasła, w pakiecie shadow używa się dwubajtowego pola salt, które zwiększa liczbę możliwych kodowań 4096 razy.

Należy jednak mieć na uwadze fakt, że system shadow nie jest do końca bezpieczny. Dokładniej: mogą zaistnieć pewne okoliczności, w których włamywacz może dostać się do zawartości tego pliku. Najczęściej sytuacje te wywołane są przez zrzuty pamięci (ang. core), w których można doszukać się zawartości pliku shadow, np.:

http://www.atomicfrog.com/archives/exploits/Xnix/SHADOWYANK.C

Jeśli mamy zainstalowany w systemie pakiet shadow, a mimo to włamywaczowi uda się odczytać plik z hasłami, to może on spróbować wykonać atak wymierzony w hasło. 'Atak na hasło' to ogólny termin opisujący różne czynności, których celem jest ominięcie mechanizmów ochrony systemu komputerowego opartych na systemie haseł, a więc wszelkie próby złamania, odszyfrowania lub skasowania haseł. Ataki na hasło to najprymitywniejsze metody włamywania się do systemu. Każdy początkujący haker zaczyna zwykle od łamania systemu haseł. Należy jednak pamiętać, że ataki na hasło mimo łatwości wykonania wcale nie muszą dawać szybko rezultatu.

Atakiem na hasło jest m.in. tzw. atak siłowy. Polega na odgadywaniu hasła użytkownika wprowadzając go do systemu. Atak ten jest zupełnie nieefektywny, gdyż zgadując hasło musimy sprawdzić ogrom możliwości - system będzie albo silnie obciążony, albo nie pozwoli na wielokrotne, następujące po sobie sprawdzenia - np. wymusi kilkusekundową przerwę po trzech nie udanych próbach.

Atak słownikowy jest lepszym przykładem ataku na hasło. Atak taki polega na tym, że włamywacze korzystają z gotowych słowników, które szyfrują przy pomocy algorytmu DES. Czyli wykonują takie same działania co system podczas logowania użytkownika do systemu. Zaszyfrowane hasła ze słownika porównują do tych uzyskanych z /etc/shadow.

Powodzenie takiego ataku ma dwa uzasadnienia:

Programy pozwalające odczytać hasła kodowane algorytmem DES:

Przy pomocy tych programów możemy zobaczyć, że hasła przez nas układane są dość łatwe do złamania. Mocne hasło jest jednocześnie trudne do ułożenia. Istotnym jest przy tym fakt, że użytkownicy rzadko kiedy podejmują jakiekolwiek wysiłki, by skonstruować sensownie trudne hasło. Dla tego najlepszym rozwiązaniem problemu związanego z możliwością pojawienia się w systemie haseł, które można szybko zgadnąć, jest niedopuszczenie do tego, by w ogóle zaistniały w systemie. Jeśli hasła testować będziemy już w programie służącym do ustalania lub zmiany hasła użytkownika (nazywa się to proaktywnym testowaniem haseł) nasz system zawczasu pozbędzie się możliwej do pojawienia luki. Przykłady programów proaktywnego testowania haseł: passwd+, anlpasswd, npasswd.

3.2. Niebezpieczne programy.

Do grupy programów niebezpiecznych dla systemu zalicza się wszystkie programy typu SUID oraz SGID. SUID oznacza tyle co Set User ID i program posiada ustawiony tryb 4000, a SGID to Set Group ID i program ma ustawiony tryb 2000. Niebezpieczeństwo płynące z programów tego typu (a zwłaszcza z ustawionym bitem SUID) polega na tym, że wykonywane są one z prawami ich właściciela. Jeśli na przykład mamy program
z ustawionym bitem SUID (np. passwd dla którego po pełnym wylistowaniu mamy: -r-s--x--x), którego właścicielem jest operator systemu root zawsze będzie uruchamiany tak, jakby to właśnie root go uruchomił. Dla tego jeśli włamywaczowi uda się wykorzystać słabość programu typu SUID (a wyszukiwanie takich słabości jest ułatwione w wszelkiego rodzaju skryptach), to potencjalnie może uzyskać uprawnienia operatora systemu.

Należy również pamiętać, że sprytny użytkownik może spróbować przynieść na dyskietce przygotowanego shell'a, którego właścicielem jest root i ma on ustawiony bit SUID, choć obecnie większość systemów Linux/UNIX jest zabezpieczona na taką ewentualność.

Sposoby ochrony przed atakami wykorzystującymi pliki typu SUID i GUID:

3.3. Szkodliwe programy.

Szkodliwe programy to programy (lub urywki programów) potocznie nazywane wirusami. Szkodliwym programem jest również koń trojański. Jest wiele innych przykładów szkodliwych kodów, ale te dwa są najgroźniejsze.

3.3.1 Koń trojański.

Koń trojański (ang. trojan) to program, który został zmieniony przez działającego
w złym zamiarze programistę.

Jeszcze niedawno, bo zaledwie 2 lata temu, na komputerach Wydziału Zarządzania AGH bardzo łatwo można było uruchomić konia trojańskiego. Znajdujący się tam NovellNetWare na początku swojego działania wyświetlał okienko proszące wpisać login i hasło. Następnie użytkownik był lub nie wpuszczany do systemu.

Konia na tych komputerach można było wprowadzić i uruchomić w następujący sposób:

W laboratorium zwykle znajduje się wiele komputerów i z wszystkich z nich po zalogowaniu się był dostęp do wspólnego dysku. Wystarczyło teraz logować się na kolejnych maszynach
i ... uruchamiać program.

Sam program został napisany w jeden wieczór. Z małymi poprawkami już drugiego dnia wieczorem działał w laboratorium i w ciągu godziny udało się zebrać prawie 30 haseł.

W UNIXie moglibyśmy wyobrazić sobie program /bin/login, który byłby nieco lepszą wersją - logowałby normalnie do systemu, ale przy okazji zapisałby sobie gdzieś na boku logi i hasło logującego się użytkownika.

http://samarac.hfactorx.org/Exploits/login_trojan.c

Konie trojańskie stanowią poważne zagrożenie z kilku powodów:

Dlatego zawsze należy uważać przy pobieraniu programów z Internetu. Najlepiej robić to
z zaufanych serwerów (dla Linux'a może to być np.: ftp.task.gda.edu.pl) i zwracać uwagę na sumy kontrolne (o sumach kontrolnych powiemy dalej).

Wykrywanie koni trojańskich zazwyczaj polega na wyszukaniu podejrzanych zmian
w plikach dyskowych. Inną metodą może być próba zdebugowania programu, albo nawet oglądniecie jego kodu maszynowego w najprostszym edytorze w celu wyszukania nietypowych komunikatów. Jeśli np. w programie jak w/w login znaleźlibyśmy string postaci: "Segmentation Fault", który jest komunikatem normalnie tworzonym przez mechanizmy systemu, od razu moglibyśmy stwierdzić, ze coś jest nie tak.

Wirusy komputerowe dzielimy na dwie podstawowe kategorie:

Częściej można spotkać wirusy drugiej grupy. Procedura dołączania kodu wirusa do plików nazywana jest infekowaniem lub zarażaniem. Zainfekowany plik nazywamy nosicielem, ponieważ potrafi zarażać inne pliki - proces taki nazywamy powielaniem kodu wirusa.

Większość wirusów nie niszczy danych - po prostu infekują pliki i dyski. Są oczywiście wirusy, które niszczą dane - wybrane pliki, lub całe dyski. Dawniej przenoszenie się wirusów głównie odbywało się drogą, którą wędrowały dyskietki je zawierające. Obecnie za pośrednictwem Internetu wirusy potrafią w ciągu kilku godzin zarazić tysiące komputerów. Na przykład: około 26 marca 1999 roku opublikowano na grupie dyskusyjnej wirus oparty na makrze Worda, Melissę. 72 godziny później organizacja CERT zanotowała 100 000 zarażeń. Wirus infekował pliki Worda, Outlooka. Sam rozsyłał się do pierwszych 50 osób z książki adresowej.

Większość wirusów, podobnie jak Melissa, atakuje komputery z systemem Microsoftu. Trudno ustalić obecną liczbę wirusów i ich mutacji atakujących systemy tego typu, ale raporty twórców programów antywirusowych (np. Norton Anty Virus, czy Antyviral Toolkit Pro) podają tę liczbę w dziesiątkach tysięcy. Bardzo niewiele natomiast (dokładnie trzy) wirusów potrafi zainfekować komputer UNIX'owy. Wynika to z faktu, że UNIX przydziela dostęp do zasobów na podstawie właściciela i grup. Wirus uruchomiony przez dowolnego użytkownika nie otrzyma praw do zapisu w dowolnym miejscu. Można by się pokusić
o stwierdzenie, że również WinNT z włączoną obsługą NTFS jest odporny na wirusy. Niestety niepoprawne prawa dostępu nowo zainstalowanego oprogramowania, jak również intensywne korzystanie z języków makr bardzo ułatwiają wirusom zarażanie takich systemów.

Proces wykrywania szkodliwego kodu (konia trojańskiego lub wirusa) możemy ułatwić sobie tworząc zaraz po instalacji systemu jego obraz na trwałym nośniku (np. CDROM). Wykrywanie szkodliwego kodu polega wówczas na porównywaniu obecnego stanu z tym zapisanym na krążku. Porównywanie nie może polegać tylko na odczytaniu daty utworzenia, rozmiaru, itp. Te wartości łatwo jest oszukać edytując zawartość dysku bez pośrednictwa systemu plików. Trzeba porównać całą zawartość porównywanych plików - bit po bicie.

Lepszą i bardziej efektywną metodą jest porównywanie tzw. sum kontrolnych. Sumy kontrolne są to wartości numeryczne reprezentujące sumy bitowe plików. Często wykorzystuje się je przy transferowaniu danych - strona otrzymująca porównuje sumę kontrolną z faktycznie otrzymanymi danymi i w ten sposób określa czy podczas przesyłania nie wystąpił błąd. Najprostszym programem do tworzenia sum kontrolnych jest program sum. Program ten tworzy 16-bitowe liczby dla podanych plików. Jeśli na przykład mamy w katalogu pliki:

-rw-r--r-- 1 krz krz 0 mar 21 12:26 a.txt

-rw-r--r-- 1 krz krz 1410 mar 19 14:03 bezpieczeństwo.txt

-rw-r--r-- 1 krz krz 11128 mar 20 14:53 referat.kwd

-rw-r--r-- 1 krz krz 26467 mar 20 22:18 referat.txt

-rw-r--r-- 1 krz krz 182 mar 21 11:30 tekst.html

to wywołując polecenie: sum * otrzymujemy:

00000 0 a.txt

46067 2 bezpieczeństwo.txt

50204 11 referat.kwd

64453 26 referat.txt

32850 1 tekst.html

Pierwsza liczba to właśnie suma kontrolna, a druga oznacza liczbę bloków w pliku (zaokrągloną w górę).

Aby stworzyć najprostszy obraz systemu wydajemy polecenie:

sum `find / . -print` > sumy_kontrolne.txt

Do tego możemy napisać jakiś skrypt, który okresowo porównuje zawartość pliku z sumami kontrolnymi z aktualnym stanem i informuje nas w przypadku wystąpienia nieprawidłowości.

Podobnym programem do sum jest cksum. Ten program tworzy 32-bitową sumę CRC32 (ang. Cyclical Redundancy Checking).

Takie sumy nadal nie stanowią doskonałej kontroli spójności systemu. O wiele lepszym jest algorytm mieszający MD5. Algorytm ten tworzy 128 bitowy podpis cyfrowy dostarczanych danych. Program wykorzystujący ten algorytm md5sum w naszym przykładzie daje taki wynik:

d41d8cd98f00b204e9800998ecf8427e a.txt

b5b97055b74359364544a65e726a5c21 bezpieczeństwo.txt

c799013d05d55347f0eb36fe2d3041c0 referat.kwd

9b2189c611273b00f722d81923c8ccf6 referat.txt

bdf7084879611f6764bfacf6cc797b53 tekst.html

Bardzo dobrym programem wspomagającym kontrolowanie spójności systemu jest Tripwire. Wykorzystuje on algorytmy: CRC32, MD2/4/5, SHA i Snerfu.

Podczas testów próbowano stworzyć plik o takim samym podpisie co /bin/login (po prostu plik - pominięto sprawdzanie, czy będzie działał czy nie). Użyto 130 komputerów Sun i w ciągu kilku tygodni stworzono 2^24 (około 17 milionów) podpisów - nie przebadano 10^15. Tak więc widać, że stworzenie dwóch plików o różnej zawartości a identycznych podpisach cyfrowych jest niemal niemożliwe.

http://www.ja.net/CERT/Software/tripwire/Tripwire.PS

Inne narzędzia wspomagające badania spójności plików:

4. Bezpieczeństwo w sieci lokalnej.

Jak to w poprzednim rozdziale zostało powiedziane, dla administratora systemu nie jest najgroźniejsze włamanie polegające na zmienia kilku rzeczy na stronie WWW systemu. Najgroźniejsze są włamania, które nie są szybko identyfikowane (odnajdywane
i rozpoznawane), w których dane nie tyle są niszczone, co wykradane poprzez sieć. Dla wielu firm o wiele bardziej korzystne by było utracić pewne dane, które w jakimś stopniu można by było odzyskać (np. z backupów), niż ich wykradnięcie do firm konkurencyjnych. Dla tego bezpieczeństwo systemu od strony sieci jest również niezwykle istotne.

Poprzez sieć (a zwłaszcza sieć lokalną) można do atakowanego systemu dostać się wykorzystując trzy podstawowe, najpopularniejsze i najgroźniejsze techniki:

4.1 Węszyciel.

Podczas normalnej pracy stacji roboczej potrafi ona odbierać pakiety, które zawierają w polu adresu docelowego właśnie jej adres. Możliwe jest również ustawienie karty sieciowej w tzw. tryb bezładny (ang. promiscous mode) i wówczas możliwe jest odbieranie wszystkich pakietów przychodzących do komputera. Mając na względzie fakt, że wiele (większość) aplikacji działających w sieci nie wykorzystuje nawet najprostszych metod szyfrowania, można w łatwy sposób przechwycić i odczytać zawartość wszystkich nie szyfrowanych plątających się po sieci pakietów. Jeśli natrafimy na pakiety wędrujące do serwera i niosące ze sobą login oraz hasło do systemu (np. telnet czy ftp), to wyłapując takie pakiety
i odczytując ich zawartość dostajemy na tacy klucz do systemu.

Program przełączający kartę w tryb bezładny i nasłuchujący pracę w sieci nazywamy węszycielem (ang. sniffer). Węszyciel to program, który zwykle wykorzystuje pliki nagłówkowe: linux/if.h, linux/if_ether.h, linux/in.h, linux/ip.h, stdio.h, sys/socket.h, tcp.h. Przy ich pomocy możemy wywołać: przełączenie interfejsu w tryb bezładny, nasłuchiwanie, zapisywanie i wyświetlanie nasłuch ruchu TCP.

Najpopularniejsze węszyciele:

Niebezpieczeństwo dla systemu ze strony węszycieli jest bardzo duże, gdyż można tą drogą przechwycić hasła. A jak wiadomo dostanie się do systemu nawet jako zwykły użytkownik to połowa sukcesu dla włamywacza. Ataki przeprowadzane przy użyciu węszycieli to najgroźniejsze i najbardziej niebezpieczne ataki na system i poufne informacje.

Niełatwo jest wykryć węszyciela. Najczęściej nie zostawiają one żadnych śladów - przecież działają na komputerze atakującego i tylko przyjmują pakiety - żadnych danych podczas prowadzenia nasłuchu nie wpuszczają (chyba, że komputer zostanie zapytany) do sieci.

Czy dana karta pracuje w trybie bezładnym możemy odczytać posługując się poleceniem ifconfig. Aby sprawdzić wszystkie karty pod względem trybu pracy możemy też posłużyć się poleceniem ifstatus. W przypadku ustawionego interfejsu w tryb bezładny otrzymamy stosowny komunikat. Jest jednak poważna wada tego rozwiązania: przecież, aby wykryć węszyciela nie będziemy biegać do każdej stacji i sprawdzać jej ustawienia !

Dobrym rozwiązaniem jest użycie programu NEPED (Network Promiscous Detector). NEPED skanuje sieć w poszukiwaniu interfejsów znajdujących się w trybie promiscous.
W tym celu NEPED wykorzystuje błąd w implementacji arp. Niestety (?) w jadrach powyżej 2.0.36 (mowa o linuxach) naprawiono już ten błąd.

Najlepszą ochroną przed węszycielami jest zastosowanie szyfrowania zarówno transmisji loginu i hasła jak i samych danych.

4.2 Skaner.

Skaner to program automatycznie wyszukujący luki w systemie. Najprostszy skaner wyszukujący wszystkie programy root'a w /sbin, w których bit SUID jest ustawiony
i programy te mogą być używane przez wszystkich użytkowników może wyglądać tak:

find /sbin/ -perm -4505

Przykładowy wynik działania (z wylistowaniem tych programów):

-rwsr-xr-x 1 root root 1276536 paź 27 14:58 /sbin/linuxconf*

-rwsrwxrwx 1 root root 11691 mar 20 20:02 /sbin/pgr*

-rwsr-xr-x 1 root root 15692 paź 2 07:42 /sbin/pwdb_chkpwd*

-r-sr-xr-x 1 root root 16236 paź 2 07:42 /sbin/unix_chkpwd*

Samo odnalezienie takich programów jeszcze niewiele nam daje, ale mamy już jakiś punkt zaczepienia - przykład ilustruje istotę działania skanera. Jeśli wiedzielibyśmy jak wykorzystać słabość np. /sbin/linuxconf, to mamy włamanie gotowe.

Różne skanery wyszukują różne luki, ale wszystkie można podzielić na dwie kategorie:

4.2.1 Skaner systemowy.

Skanery systemowe badają host lokalny, poszukując luk w bezpieczeństwie wynikających z przeoczeń, drobnych błędów w administracji oraz problemów przy konfiguracji, które miewają nawet doświadczeni użytkownicy. Przykładem skanera systemowego może być COPS (Computer Oracle and Password System). Jeszcze darmowy COPS można pobrać z:

COPS wyszukuje w systemie typowe błędy konfiguracyjne, luki, itp. Znajduje np.: nieprawidłowe prawa dostępu do plików, katalogów i urządzeń, wyszukuje słabe hasła, nieprawidłowo ustawione bity SUID i SGID, podejrzane zmiany w sumach kontrolnych plików.

4.2.2 Skaner sieciowy.

Skaner sieciowy, natomiast, testuje hosty poprzez łącza sieciowe - tak jakby to robił kraker. Skanery sieciowe sondują dostępne usługi i porty, poszukując ogólnie znanych luk, które mogłyby zostać wykorzystane przez atakującego.

Przykładem skanera sieciowego może być ISS (Internet Security Scanner). Program ISS jest pierwszym narzędziem w swoim rodzaju. Rozpoznaje on uruchomione usługi i testuje je pod kątem znanych luk w bezpieczeństwie, które można wykorzystać zdalnie. To właśnie główne cechy każdego skanera sieciowego.

Obecnie za jeden z najlepszych skanerów sieciowych uważa się program SATAN (Security Administrator's Tool for Analyzing Networks), który po raz pierwszy ukazał się 5 kwietnia 1995 roku.

SATAN jest pierwszym programem, w którym za pomocą jednego kliknięcia można przeprowadzać złożone testy systemu. SATAN składa się z wielu modułów skanujących, wykrywających luki w zabezpieczeniach zdalnych hostów. Bada m.in.:

Program do wyświetlania raportów wykorzystuje możliwości Perla i zwykłą przeglądarkę interpretującą HTML'a. Rapotry są niezwykle przejrzyste i ścisłe zarazem. To właśnie dzięki nim SATAN zyskał ogromną popularność.

Należy pamiętać, ze skanery to nie tylko wyszukiwacze luk w naszym systemie, które może wykorzystać włamywacz. To przede wszystkim nieoceniona pomoc w wyszukiwaniu owych luk, które powinniśmy załatać.

Przykłady innych skanerów:

http://www.wwdsi.com/saint

Legalność skanerów sieciowych to temat dyskusyjny. Niektórzy uważają, że przeczesywanie obcego systemu to naruszenie prywatności - przypomina przecież buszowanie wokół domu
z nadzieją wyważenia drzwi albo okna. Inni stoją na stanowisku, że uruchamiając serwer
w Internecie wyraża się przynajmniej domniemaną zgodę na skanowanie. W końcu adres sieciowy można porównać do numeru telefonicznego: każdy ma prawo go wykręcić. Przepisy prawne nie regulują jeszcze tej kwestii. Tak więc prawnie skanowanie jest legalne.

Przed skanerami nie da się ukryć. Jeśli chcemy choćby obserwować ich działania możemy posłużyć się różnymi ku temu celowi stworzonymi programami. Np.:

4.3 Podszywanie.

Podszywanie najczęściej polega na działaniu mającym na celu przeprowadzenie procesu autoryzacji z jednego komputera do drugiego poprzez sfałszowanie pakietów tak, by wyglądały jak z zaufanego hosta. Techniki podszywania możemy podzielić na trzy kategorie:

4.3.1 Podszywanie IP.

Podszywanie IP polega na wykorzystywaniu słabych punktów strategii sterowania dostępem do sieci na podstawie nazwy hosta. Taka strategia występuje w Internecie bardzo często. W tym podejściu zabezpiecza się jeden serwer, lub (np. przy pomocy TCP Wrappers) kilka usług, a nawet całe sieci (zapory sieciowe). Narzędzia te różnią się między sobą, ponieważ zostały stworzone do konkretnych zastosowań. Wszystkie z nich mają jednak pewną cechę wspólną: do rozpoznawania używają adresu źródłowego lub adresu IP łączącego się komputera. Często w plikach konfiguracyjnych wielu aplikacji (choćby serwer apache) możemy znaleźć zapisy postaci:

AllowHosts nazwa.hosta.domena, ip.sieci.*

DenyHosts inny.host.inna.domena

Takie wpisy, w zależności od aplikacji, mogą dotyczyć całych podsieci, indywidualnych hostów, czy poszczególnych użytkowników.

Jak łatwo można zauważyć, pojedynczy pakiet zawiera między innymi numer IP źródła. Numer ten jest na tyle nie powtarzalny, że w danej sieci czy podsieci nie mogą się znaleźć dwa komputery z tym samym IP. Niestety to host wpisuje adres źródłowy i jeśli dany program wykorzystuje autoryzację czy identyfikację na podstawie tylko numeru IP, to system docelowy nie ma możliwości poznania prawdziwego miejsca pochodzenia pakietu.

Przykładem programu, który wykorzystuje autoryzację na podstawie adresu źródłowego IP jest system rhosts. Na podstawie wpisu w pliku .rhosts użytkownicy zdalni mogą otrzymać dostęp do danego komputera za pośrednictwem usług 'r' bez podawania hasła.

Sama luka w systemie rhosts nie daje jeszcze możliwości włamania się do danego systemu. Protokół TCP posiada mechanizm kontroli polegający na numeracji pakietów (ang. numbering sequence). Jeśli podczas nawiązywania połączenia komputer atakowany wyśle pakiet SYN to komputer starający się o autoryzację musi odgadnąć wartość numeru sekwencyjnego tego pakietu i odpowiedzieć numerem o jeden większym. Ale skoro komputer podszywający się wyśle pakiet z adresem źródłowym innego komputera (sam jest nie autoryzowany) to od atakowanego komputera nie dostanie żadnych pakietów w odpowiedzi. Pakiety te pójdą natomiast do komputera, za którego atakujący się podaje. Połączenie nie zostanie nawiązane.

Dobrym rozwiązaniem tego problemu jest zablokowanie (przez np. zalanie pakietami SYN) komputera za którego komputer atakujący się podaje tak, by nie mógł on odpowiadać na pakiety komputera atakowanego. Następnie samplujemy pakietami SYN komputer atakowany by odgadnąć w jaki sposób generuje on swoje numery sekwencyjne. Widząc już jaki będzie najbliższy numer sekwencyjny serwera wysyłamy pakiet z komputera atakującego ale
z adresem źródłowym autoryzowanego komputera. W domyśle wiemy, że serwer odpowie na 'nasze' żądanie wysyłając swój pakiet. Ten pakiet nie dotrze do komputera atakującego. Do autoryzowanego też nie, bo ten jest zalany tak, by nie mógł odpowiadać. Ponieważ wiemy jaki numer sekwencyjny wysłał serwer odpowiadamy numerem o jeden większym (znów
z adresem źródłowym komputera autoryzowanego) i w ten sposób otrzymujemy nawiązanie połączenia. Teraz wystarczy wykonać na atakowanym komputerze polecenie:

echo ++ > .rhosts i mamy otwartą furtkę do systemu.

Programem wykorzystującym powyższy algorytm jest

Inne programy i narzędzia pomocne w podszywaniu:

Na podszywanie IP podatne są usługi:

Najprostszym zabezpieczeniem przeciw podszywaniu IP jest unikanie wykorzystywania adresu IP do autoryzacji. Obecnie bardzo dobrze rozwinięte są techniki szyfrowania, które zupełnie eliminują konieczność autoryzacji w ten sposób.

Można by było udoskonalić generator kolejnych numerów sekwencyjnych, ale nigdy nie zastąpi to szyfrowania. Podpatrując kilka kolejnych liczb wciąż jeszcze można odgadnąć sposób ich generowania.

Dodatkowo możemy skonfigurować ruter tak, aby nie wpuszczał do sieci lokalnej pakietów podających w swoim adresie źródłowym numerów IP z tej sieci.

4.3.2 Podszywanie ARP.

Podszywanie ARP (ang. Address Resolution Protocol) to bardzo podobny sposób podszywania co podszywanie oparte o IP. W protokole ARP autoryzacja jest także oparta na adresie, ale tym razem jest to adres sprzętowy MAC.

Kiedy host zamierza rozpocząć sesję, wysyła komunikat ARP z adresem IP komputera docelowego. Dla usprawnienia komunikacji istnieje pamięć podręczna adresów ARP, pozwalająca na szybkie połączenie hostów bez konieczności rozsyłania komunikatu. To właśnie pamięć podręczną wykorzystują agresorzy przy atakach z wykorzystaniem podszywania ARP.

W podszywaniu ARP atakujący zatrzymuje swój adres sprzętowy, ale przyjmuje adres IP hosta 'zaufanego'. W tym celu wysyła błędne informacje o tłumaczeniu adresów zarówno do komputera atakowanego, jak i do pamięci podręcznej. Od tej pory pakiety z komputera atakowanego przesyłane są pod adres sprzętowy komputera atakującego. Ofiara "wierzy", że maszyna atakującego to właśnie 'zaufany' host.

Jest kilka sposobów na zabezpieczenie przed podszywanie ARP. Jednym z nich jest wpisanie tłumaczenia adresów na stałe. Jest to jednak nie wygodne i dość kłopotliwe ze względu na nieelastyczność mechanizmu w przypadku jakichkolwiek zmian w strukturze sieci.

W systemie Linux obsługę translacji między adresami sprzętowymi MAC a IP możemy wykonywać przy pomocy polecenia arp. System ARP będzie pozwalał na odczytywanie przychodzących pakietów w dwóch sytuacjach:

Program posiada wiele opcji wywołania, ale najważniejsze i najczęściej używane z nich to:

Address HWtype HWaddress Flags Mask Iface

wins.ms.agh.edu.pl ether 00:60:08:66:A3:C7 C eth0

iza3.ds11.agh.edu.pl ether 00:30:4F:09:23:B9 CM eth1

192.168.11.245 ether 00:00:00:00:00:00 CM eth1

192.168.11.209 ether 00:00:00:00:00:00 CM eth1

consul.ds11.agh.edu.pl ether 00:E0:7D:70:EF:48 CM eth1

Najważniejsze, to

wins.ms.agh.edu.pl (149.156.124.27) at 00:60:08:66:A3:C7 [ether] on eth0

iza3.ds11.agh.edu.pl (192.168.11.152) at 00:30:4F:09:23:B9 [ether] PERM on eth1

? (192.168.11.245) at 00:00:00:00:00:00 [ether] PERM on eth1

? (192.168.11.209) at 00:00:00:00:00:00 [ether] PERM on eth1

? (192.168.11.188) at 00:00:00:00:00:00 [ether] PERM on eth1

consul.ds11.agh.edu.pl (192.168.11.103) at 00:E0:7D:70:EF:48 [ether] PERM on eth1

Jest to bardzo podobny wpis. Pytajnik przy adresie IP oznacza, że danego adresu nie można rozinąć do postaci mnemonikowej - nie ma odpowiedniego wpisu w serwisie DNS.

192.168.11.8 00:00:00:00:00:00

192.168.11.9 00:E0:7D:79:49:72

192.168.11.10 00:D0:09:34:06:07

4.3.3 Podszywanie DNS.

Podszywanie DNS polega na włamaniu się do serwera DNS (Domain Name System)
i zmianie tablic mapowania nazw hostów na adresy IP. Kiedy klient wysyła żądanie podania adresu IP jakiegoś hosta, to w odpowiedzi otrzymuje adres podrobiony, Może to być adres IP komputera znajdującego się pod całkowitą kontrolą krakera.

Narzędzia do przeprowadzania ataków DNS:

Podszywanie DNS jest dość łatwo wykryć. Jeśli podejrzewamy któryś z serwerów DNS, należy wysłać żądania do innych serwerów DNS w sieci. Po porównaniu odpowiedzi łatwo można zauważyć wystąpienie ew. anomalii. Jedyną przeszkodę napotkamy, gdy ataku na dany serwer DNS dokonano stosunkowo dawno i tablica mapowania została przesłana do innych serwerów.

5. Bezpieczeństwo przesyłanych danych.

W poprzednim rozdziale omówiliśmy aspekty bezpieczeństwa w sieci lokalnej. W tym rozdziale zajmiemy się bezpieczeństwem przesyłanych danych zarówno w sieci lokalnej jak
i w sieci Internet.

5.1 SSH i SCP.

Secure Shell to system służący do logowania na zdalnej maszynie. Jest odpowiednikiem popularnego telnet'a, ale o wiele bezpieczniejszy. Zastępuje doskonale również rlogin, rsh, rcp i rdist. System ten umożliwia logowanie do zdalnego komputera, wykonanie na nim poleceń oraz przenoszenie plików z jednej maszyny na drugą. SSH wykorzystuje silne szyfrowanie procesu autoryzacji i zapewnia bezpieczną wymianę danych w niezabezpieczonych sieciach.

W SSH wykorzystano wiele algorytmów, m.in.:

Budowa systemu ssh wraz z obsługą wielu algorytmów to potężne narzędzie, które jest jednocześnie elastyczne i rozszerzalne. Dla głównego protokołu obojętne jest, który algorytm jest wykorzystywany. Jeśli któryś z nich okaże się podatny na złamanie, to wystarczy go po prostu wyłączyć z użycia i zstąpić którymś z innych.

Program można pobrać z http://www.ssh.fi - zawsze najlepiej pobierać źródła i kompilować je na swoim komputerze.

Dystrybucja ssh zawiera kilka różnych programów. Poniżej znajduje się ich zestawienie:

Program

Opis

make-ssh-known-hosts

Skrypt w Perlu służący do tworzenia nowej bazy danych hostów (automatycznie znajduje hosty w określonej domenie poprzez DNS).

scp

Program do bezpiecznego kopiowania plików z jednego hosta na drugi. Działa podobnie jak rcp, ale sam transfer plików wykonywany jest przez ssh.

ssh

Klient ssh. Jego działanie podobne jest do telnetu (logowanie umożliwiające wykonywanie poleceń)

ssh-add

Dodaje uzytkowników (rejestruje nowe klucze) do agenta autoryzacji ssh-agent.

ssh-agent

Przeprowadza proces autoryzacji typu RSA. Za jego pomocą zdalne hosty uzyskują dostęp i przechowują prywatne klucze RSA.

sshd

Serwer ssh domyślnie nasłuchujący na porcie 22. Po otrzymaniu żądania połączenia rozpoczyna nową sesję.

ssh-keygen

Generator kluczy dla ssh. Za jego pomocą użytkownik tworzy klucz, któśy potem używany jest do lokalnej i zdalnej autoryzacji (wykonywanej przez ssh-agent).

Po zainstalowaniu pakietu należy skonfigurować klienta ssh demona sshd. Plik konfiguracyjny dla klienta najczęściej /etc/ssh_config lub /etc/ssh/ssh_config i dla serwera odpowiednio: /etc/sshd_config lub /etc/ssh/sshd_config.

Nie będziemy tu opisywać szczegółów opcji konfigurowania serwera sshd - są one szczegółowo opisane w dokumentacji man, howto, itp.

Aby uruchomić klienta ssh w najprostszej formie, wydajemy polecenie ssh z parametrami: nazwa użytkownika oraz nazwa hosta lub numer IP, np.:

ssh -l kaczor ernie.icslab.agh.edu.pl

Serwer zapyta nas o hasło i po wprowadzeniu poprawnego hasła jesteśmy wpuszczeni do systemu i mamy możliwość normalnej zdalnej pracy tak jak w przypadku telneta.

Istotnym jest jednak, że zawsze przy pierwszym logowaniu się do zdalnego serwera wyświetlana jest wiadomość:

Host key not found from the list of known hosts.

Are you sure you want to continue connecting (yes/no)?

Jeśli to jest host, z którym chcieliśmy się połączyć wpisujemy 'yes'. Komunikat ten nie pojawi się przy kolejnym logowaniu, gdyż host ten zostanie wpisany do lokalnego pliku z hostami. Plik z hostami znajduje się w katalogu domowym użytkownika i najczęściej jest to: ~/.ssh/known_hosts

Program scp powinien być używany do przesyłania plików wszędzie tam, gdzie tylko to możliwe. Scp jest odpowiednikiem ftp (ang. File Transfer Protocol). W najprostszej formie wywołanie programu może wyglądać w następujący sposób: scp user1@host1.domena1:plik1.txt user2@host2.domena2:plik2.txt - skopiuje plik1.txt z host1 należący do user1 na konto user2 znajdujące się na host2 pod nazwę pliku plik2.txt.

Dla sieci heterogenicznych dostępne są wydania ssh:

SSH potrafi zabezpieczyć sesję telnetową po obu stronach połączenia, dzięki czemu przechwycenie hasła nie będzie mogło mieć miejsca ani po stronie serwera, ani po stronie klienta.

Oprócz zabezpieczania sesji telnetowych ssh można wykorzystać do zestawienia szyfrowanego połączenia PPP. Następnie tworzymy tunelowane połączenie między dwoma sieciami w Internecie. W ten sposób tworzy się prostą prywatną sieć wirtualną (typu VPN).

Wczesne wersje ssh posiadały błąd przepełnienia bufora i umożliwiały nawiązanie sesji użytkownikom, których konta wygasły. Problem ten nie stanowił dużego niebezpieczeństwa i w nowszych wersjach został wyeliminowany. Jednakże należy zawsze korzystać z jak najnowszej wersji ssh. Luki wcześniejszych wersji są wykrywane przez popularne skanery, np. przez SAINT'a.

6. Ataki odmowy obsługi DoS.

W najbardziej podstawowej formie, atak odmowy obsługi (DoS - ang. Denial of Service) to dowolne działanie unieruchamiające sprzęt lub oprogramowanie i powodujące zaprzestanie świadczenia usług przez system komputerowy. Cel atakującego jest prosty: host lub hosty mają przestać reagować na bodźce z zewnątrz.

Atak odmowy obsługi to dokuczliwy problem z dwóch powodów. Po pierwsze są łatwe do przeprowadzenia, a wynik ich działania jest natychmiastowy. Stąd też ich przeprowadzanie to popularne zajęcie wśród początkujących krakerów lub znudzonych nastolatków. Po drugie, wiele ataków tego typu wykorzystuje błędy, ograniczenia lub niezgodności
w implementacjach protokołu TCP/IP. Błędy te istnieją dopóty, dopóki producent oprogramowania nie stworzy odpowiedniego programu korekcyjnego. Do tego czasu wszystkie hosty pozostają podatne na atak DoS.

Typowy przykład to atak teradrop, który polegał na wysłaniu źle skonstruowanych pakietów UDP do hosta Windows. Atakowany komputer badał otrzymywane nagłówki pakietów, dławił się i powodował wystąpienie wyjątku krytycznego. Microsoft szybko przebadał implementację stosu TCP/IP i opublikował program korekcyjny.

Zasadniczo rozróżnia się trzy typy ataków DoS:

6.1 Ataki na urządzenia sieciowe.

Polegają prawie na tym samym co na ataki na usługi na serwerze. Atak polega na unieruchomieniu wybranego urządzenia sieciowego (najczęściej rutera) co powoduje wyłączenie z użycia wrażliwego węzłą. Takie problemy nie dotyczą najnowszych urządzeń sieciowych, ponieważ producenci bardzo szybko łatają dziury w oprogramowaniu i osprzęcie urządzeń.

6.2 Ataki na usługi sieciowe.

Dobrym przykładem ataku DoS na wybraną usługę może być prościutki program naszego autorstwa przedstawiony poniżej. Program nawiązuje masową ilość połączeń
z wybraną usługą - połączenia są realizowane aż do wyczerpania zasobów (brak wolnych gniazd) albo do maxymalnej ilości połączeń dla danej usługi. Jak na początku napisaliśmy, atak DoS polega na zablokowaniu danego hosta - blokada ta może dotyczyć zarówno całego hosta, jak i wybranej usługi.

Poniższy program w pętli: tworzy gniazdo sieciowe i otwiera połączenie z wybraną usługą (tu ssh - port 22) znajdującą się na wybranym hoście (tu 127.0.0.1).

#include <sys/types.h>

#include <sys/socket.h>

#include <string.h>

#include <arpa/inet.h>

void main()

{

while(1)

{

int sockfd = socket(AF_INET, SOCK_STREAM, 0);

struct sockaddr_in serveraddr;

bzero(&serveraddr, sizeof(serveraddr));

serveraddr.sin_family = AF_INET;

serveraddr.sin_port = htons(22);

inet_pton(AF_INET, "127.0.0.1", &serveraddr.sin_addr);

connect(sockfd, (sockaddr *) &serveraddr, sizeof(serveraddr));

}

}

Po skompilowaniu i uruchomieniu na Mandrake 7.2. ze standardowo skonfigurowanym sshd program ten otworzył 10 połączeń (poleceniem netstat -na | grep tcp | grep ESTABLISHED można oglądać ustanowione połączenia) i zablokował demona ssh przed kolejnymi połączeniami.

Próba wywołania: ssh 127.0.0.1

dała w rezultacie tylko komunikat: ssh_exchange_identification: Connection closed by remote host

To jest prosty i łatwy do wykrycia przykład. W najbardziej podstawowej konfiguracji syslog dostaniemy w pliku /var/log/messages wpis o ustanowionym połączeniu na podstawie, którego możemy dojść do komputera źródłowego, np.:

Apr 5 09:15:33 frog sshd[1148]: Did not receive ident string from 127.0.0.1.

Lepszym rozwiązaniem jest nie nawiązywanie pełnego połączenia. Klient wysyła pakiet SYN. Serwer odpowiada swoim pakietem SYN i potwierdzeniem pakietu klienta. Klient przerywa procedurę ustanawiania połączenia i wysyła pakiet RST. W ten sposób została wymuszona komunikacja, ale nie zostało nawiązane połączenie. W logach komputera, do którego wysyłamy takie żądania nie zostanie nic zapisane.

Takie postępowanie nazywa się 'skanowaniem półotwartym'. Normalnie takie skanowanie nie powoduje odmowy obsługi, ale jeśli będziemy wykonywali je bardzo szybko i z dużą częstotliwością, zalewając host pakietami zawierającymi znacznik RST to czasem może to doprowadzić do zawieszenia demona inetd.

Niezamierzony, ale często skuteczny atak tego typu można przeprowadzić skanerem NMAP, więcej:

Zupełnie skrajnym pod względem obcinania procedury łączenia przykładem jest zalewanie hosta pakietami SYN, tzw. SYN-flood. Takie zalewanie powoduje, że dany komputer może przestać odpowiadać na jakiekolwiek wiadomości.

Taki atak przeprowadzono w grudniu 1996 roku, w sezonie największych zakupów, kiedy unieruchomiono jednego z największych usługodawców internetowych WebCom. Przez 40 godzin nie działało ponad 3000 stron internetowych. Atak polegał na wysyłaniu do serwera WebCom 200 wiadomości na sekundę.

Kiedyś ataki odmowy obsługi postrzegano jako uciążliwy, ale nie najgroźniejszy problem.
W końcu większość usług unieruchomionych przez taki atak można po prostu zrestartować. Niestety jeśli weźmiemy pod uwagę, że obecnie jeden serwer oferuje wiele usług, które można zaatakować problem ten staje się uciążliwy i powoduje marnowanie wiele cennego czasu co pociąga za sobą (jak w przypadku ataku na serwer WebCom) ogromne straty materialne.

Przykłady ataków DoS na usługi sieciowe:

ping -l 65510 nazwa_hosta - większość systemów (w tym Windows 98) jest już odporna na

tego typu ataki.

6.3 Ataki na aplikacje.

Ataki na aplikacje polegają na zawieszeniu danego programu (najczęściej przeglądarki) poprzez wysłanie do niego niestandardowe dane. Np. wysyłając do starego Netscape Communicatora zawartość tworzoną przez skrypt postaci: print "Content-type: internal/parser\n"; spowoduje zawieszenie przeglądarki.

Innym przykładem ataku na aplikacje może być wywołanie w starych wersjach Red Hat
z programem passwd-0.50-7 polecenia passwd z konkretnie określonymi wielkościami plików. Jeśli /etc/passwd przekracza ten limit, to passwd nie jest w stanie zapisać zmian do pliku i kończy działanie. Plik /etc/passwd zostaje zablokowany i nie przyjmuje zmian w bazie haseł. Rozwiązaniem jest aktualizacja passwd.

Nie ma ogólnej zasady obrony przed atakami odmowy obsługi. Można jednak nieco uodpornić swoją sieć, jeśli pamięta się o następujących zasadach:

7. Firewall'e i proxy serwery.

Zwykle organizacja dostępu do Internetu w firmie, akademiku, bloku czy jakiejkolwiek organizacji polega na tym, że wszystkie komputery z sieci wewnętrznej (Local Area Network) łączą się z Internetem poprzez jeden wybrany komputer (lub inne urządzenie sieciowe: ruter, 'firewall-in-a-box'), który posiada dwie karty sieciowe: jedną do łączenia sie
z siecią lokalną, drugą do łączenia się z Internetem. Przy takiej architekturze sieci cały ruch między komputerami z zewnątrz a komputerami z naszej sieci odbywa się poprzez ten właśnie dedykowany komputer. Jest on zatem odpowiedzialny za utrzymanie tego ruchu i za jego kontrolę. Jeśli zważymy na fakt, że Internet to dziki busz pełen agresywnych ludzi, którzy tylko czyhają na najdrobniejsze luki by dla zabawy lub w innych celach unieruchomić któryś z komputerów z naszej sieci lub ukraść jakieś dane, to zrozumiemy, że odizolowanie sieci wewnętrznej od Internetu jest bardzo ważne. Jeśli na dodatek wszystkie komputery
z naszej sieci kontrolowane są przez użytkowników i nie mamy dużego wpływu na ich konfigurację, to należy zdać sobie sprawę z tego, że niedoświadczeni i lekceważący użytkownicy często zostawiają wiele nie zabezpieczonych luk w swoich komputerach.

Firewall, czyli "ściana ogniowa", to termin wzięty z konstrukcji samochodu. W samochodach firewalle fizycznie oddzielają silnik od pasażerów. To znaczy, że chronią one pasażerów
w wypadku, gdy silnik zapali się cały czas dostarczając kontroli nad nim.

Komputerowe firewalle generalnie dzielą się na dwa rodzaje:

W zależności od typu zapory sieciowej, ochrania ona naszą sieć przynajmniej na dwa sposoby z trzech poniższych:

7.1 Firewalle filtrujące.

Firewalle filtrujące działają na poziomie pakietów IP. Są zaprojektowane do kontroli przepływu bazując na:

Przy czym można rozróżnić trzy podstawowe sytuacje w jakich pakiet poddawany jest filtrowaniu:

Jednym z rozwiązań jest ustawienie firewalla na komputerze, który jest gateway'em dla danej podsieci.

Rozważmy przykładową sytuację, w której pakiet przechodzi filtrowanie. Wyobraźmy sobie sytuację jak na rysunku poniżej (przykład zaczerpnięty z konfiguracji na MS AGH):

0x01 graphic

W tej konfiguracji mamy pokazane dwa wybrane firewall'e na komputerach PC
z systemem Linux (Linux posiada opcję filtrowania pakietów w jądrach powyżej 1.3.x), jeden dla podsieci znajdującej się w DS-11, drugi dla DS-4. Obie podsieci mają do siebie i do Internetu dostęp poprzez ruter. W takiej konfiguracji możemy rozróżnić dwa sposoby wymiany pakietów: jeden między komputerami znajdującymi się w obrębie rutingu AGH, drugi między komputerem z którejś z podsieci a komputerem z zewnątrz.

Postawmy najpierw pewne założenia:

I. Wymiana pakietów między bart.ds11.agh.edu.pl a albert.ds4.agh.edu.pl.

Ponieważ wewnątrz MS AGH wszystkie adresy są niepowtarzalne (mimo, że są to adresy
z puli adresów prywatnych), więc nie ma potrzeby prowadzenia wewnętrznej translacji adresów (masqeradeing'u) i komputery takie jak bart.ds11 i albert.ds4 mogą komunikować się ze sobą i być wzajemnie identyfikowane.

Załóżmy, że komputer albert.ds4 posiada witrynę WWW, a przeglądarka na bart.ds11 chce pobrać z niej stronę. Pakiet z żądaniem nawiązania połączenia tcp od bart.ds11 będzie szedł
w następujący sposób (przy opisie pakietów pomijamy opis typu pakietu):

W komputerze albert.ds4 żądanie jest analizowane i jeżeli wysyłany jest pakiet z albert.ds4 do bart.ds11 to przechodzi on analogiczną drogę - do wyznaczenia drogi zamienione są tylko pola cech źródła i celu w pakiecie.

II. Wymiana pakietów między bart.ds11.agh.edu.pl a www.wp.pl:

Jeśli klient (przeglądarka) znajdujący się na bart.ds11 zażąda połączenia z serwerem www.wp.pl, to żądanie to musi być przesłane w pewien a odpowiedź będzie odebrana w nieco inny sposób. Otóż adresy prywatne posiadane przez komputery na MS AGH nie mogą być widziane z Internetu, więc muszą one być maskowane na takie adresy, które w sieci zewnętrznej mogą się pojawić. Takie pakiet przebędzie swoją drogę w następujący sposób:

Droga powrotna w jednym miejscu odbiega od prostej odwrotności:

Tak mniej więcej wygląda droga pakietów między komputerami na MS AGH i komputerami z Internetu.

Jak łatwo można zauważyć, wszystkie komputery znajdujące się wewnątrz rutingu AGH widzą siebie nawzajem po swoich numerach IP (a w szczególności nazwach hostów). Natomiast na zewnątrz (w Internecie) komputery z wewnątrz rutingu AGH są widoczne albo po swoich adresach IP, jeśli są to adresy rutowalne, albo po adresach serwerów, przez które są maskowane.

Aby uruchomić w Linuxie uruchomić obsługę filtrowania pakietów i maskowania komputerów z LAN należy:

7.1.1 ipachains/ipfwadm.

Najpopularniejszym narzędziem Linuxowym do obsługi firewalla jest ipchains, następca ipfwadm. ipchains jest standardowo dołączanym pakietem do większości dystrybucji Linuxa. Program ten posiada wiele opcji, których nie będziemy z osobna wymieniać, natomiast pokażemy konkretny przykład konfiguracji firewalla. Załóżmy, że konfigurujemy firewalla na komputerze z rysunku: spider.ds11.agh.edu.pl. Przyjmijmy sobie taką politykę: z serwera wypuszczamy bezwzględnie cały ruch, blokujemy ruch wchodzący
i forwardowany.

Ustalenie polityki:

/sbin/ipchains -P input DENY

/sbin/ipchains -P output ACCEPT

/sbin/ipchains -P forward DENY

Wyczyszczenie wszystkich reguł we wszystkich łańcuchach filtrowania:

/sbin/ipchains -F

Usunięcie wszystkich nie wbudowanych łańcuchów (wbudowane to tylko ACCEPT, DENY, REJECT i MASQ):

/sbin/ipchains -X

Skasowanie wszystkich liczników pakietów:

/sbin/ipchains -Z

Zezwolenie na wejście pakietów skądkolwiek przez interfejs eth0, kierowanych do komputera spider lub sieci ds11 (-s adres/maska źródła, -d adres/maska celu, -i interfejs, -j skok do wybranego łańcucha):

/sbin/ipchains -A input -s 0/0 -d 149.156.124.11/32 -i eth0 -j ACCEPT

/sbin/ipchains -A input -s 0/0 -d 192.168.11.0/24 -i eth0 -j ACCEPT

Jeśli pakiety są z komputerów z rutingu AGH, a kierowane są do sieci ds11, to forwarduj je na interfejs eth1:

/sbin/ipchains -A forward -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT

/sbin/ipchains -A forward -s 192.168.11.0/24 -d 149.156.96.0/19 -j ACCEPT -b

/sbin/ipchains -A forward -s 192.168.11.0/24 -d 149.156.192.0/21 -j ACCEPT -b

Opcja -b powoduje wstawienie identycznej reguły, ale z zamienionymi adresami źródła i celu.

Dostęp do napstera przez maskowanie, opjca -p pozwala określić protokół i port:

/sbin/ipchains -A forward -s 192.168.11.0/24 -d 0/0 -p tcp --destination-port 88 57 -j MASQ

/sbin/ipchains -A forward -s 192.168.11.0/24 -d 0/0 -p udp --destination-port 88 57 -j MASQ

Dostęp do serwera irc (dowolnego na określonych portach):

/sbin/ipchains -A forward -s 192.168.11.0/24 -d 0/0 -p tcp --destination-port 6660:6670 -j MASQ

Poczta: wszystkie serwery, porty pop3 i smtp:

/sbin/ipchains -A forward -s 192.168.11.0/24 -d 0/0 -p tcp --destination-port pop3 -j MASQ

/sbin/ipchains -A forward -s 192.168.11.0/24 -d 0/0 -p udp --destination-port pop3 -j MASQ

/sbin/ipchains -A forward -s 192.168.11.0/24 -d 0/0 -p tcp --destination-port smtp -j MASQ

Wpuszczanie pakietów od konkretnych komputerów z sieci wewnętrznej ds11 do spidera:

/sbin/ipchains -A input -s 192.168.11.3/32 -j ACCEPT # komputer bart

Każda konfiguracja ipchains ma swoje wady i zalety. Zawsze należy się dobrze zastanowić jaką politykę wyjściową ustalić. Np. gdybyśmy na serwerze z kontami shellowymi ustawili firewall, który blokuje komputerom sieci wewnętrznej poprzez forwardowanie dostęp do Internetu (tzn. input i output są ustawione na ACCEPT), to sprytny użytkownik, może spróbować na swoim koncie shellowym postawić własny serwer proxy. Poprzez blokowanie forward nie wyłączymy mu także możliwości obsługi poczty, itp.

Zapory sieciowe oparte na ruterach filtrujących są nieco lepszym rozwiązaniem niż firewalle ustawione na wybranym komputerze. Te zapory sieciowe mają jedną przeważającą zaletę: są niezależne od systemu i aplikacji - nie trzeba więc stosować specjalnych zabiegów dla różnych stacji roboczych. Niektóre rutery potrafią nawet zabezpieczyć sieć przed podszywaniem i atakami odmowy obsługi, a nawet sprawić, że nasza sieć będzie zupełnie nie widoczna dla świata zewnętrznego. Rutery to także rozwiązanie zintegrowane. Jeśli sieć podłączona ma być do internetu to i tak będziemy potrzebowali rutera. Rutery jednak to bardzo kosztowne rozwiązanie. Jeśli mamy małą sieć to lepiej wykorzystać do tego komputer z UNIX'em/Linuxem.

7.2 Serwery proxy.

Serwery proxy pozwalają na niebezpośredni dostęp do Internetu, przez firewall. Pakiety nigdy nie są przekazywane pomiędzy siecią wewnętrzną i zewnętrzną. Zamiast tego następuje rodzaj tłumaczenia, a rolę tłumacza pełni właśnie serwer proxy. Dokładniej rzecz biorąc, jeśli komputer z sieci wewnętrznej chce nawiązać połączenie z komputerem
z Internetu, to najpierw nawiązuje połączenie z serwerem proxy, który wykonuje żądanie za klienta z serwerem docelowym.

To rozwiązanie daje dużo lepszą kontrolę nad ruchem i w przypadku dobrej konfiguracji jest dużo lepsze od firewalla filtrującego pakiety. W tym rozwiązaniu nie ma praktycznie możliwości rozpoznania sieci z zewnątrz. Wynika to z faktu, że pakiety wychodzące
z serwera proxy do Internetu (sieci zewnętrznej) posiadają autentyczne dane wskazujące na pochodzenie danego pakietu od serwera a nie komputera z wewnątrz sieci. To dopiero serwer proxy sam rozpoznaje powracające pakiety i przekazuje je do odpowiednich hostów w sieci wewnętrznej.

Rozwiązanie to nie jest jednak pozbawione wad. Aby wszystko dobrze działało administrator musi skonfigurować poprawnie aplikację proxy dla każdej z usług: FTP, telnet, HTTP, mail, SSH, itp. Co więcej - użytkownicy z wewnątrz sieci muszą korzystać z aplikacji obsługujących proxy.

Najpopularniejszym dla Linuxa serwerem proxy jest squid i serwer SOCKS.

7.2.2 Squid.

Serwer squid jest serwerem proxy dla WWW. Posiada on również wbudowaną funkcję cache stron WWW. Zazwyczaj znajduje się on w dystrybucji Linuxa; jeśli nie, to znajdziemy go na każdym ftp z oprogramowaniem dla Linuxa. Po zainstalowaniu należy skonfigurować plik /usr/local/squid/etc/squid.conf (jeśli korzystamy z squid z dystrybucji, to plik ten może znajdować się gdzie indziej, np.: /etc/squid/squid.conf). Zazwyczaj jest on gotowy do natychmiastowego użycia, ale warto przejrzeć plik konfiguracyjny, żeby chociaż zorientować się na jakim porcie będzie nasz serwer proxy dostępny (jest to zazwyczaj 3128).

Można w nim również określić, gdzie będzie składowany cache naszego serwera. Jeżeli ma to być serwer dla większej ilości komputerów (np. 100), to warto poświęcić 1 GB na dysku. Wówczas nasz serwer będzie stosunkowo dobrze pracował.

Tworzymy również użytkownika squid, tak aby nie był on uruchamiany z konta root
i tworzymy katalogi dla cache: su - squid -c "/usr/local/squid/bin/squid -z"

I uruchamiamy serwer: su - squid -c "/usr/local/squid/bin/squid -D"

Obsługa squid jest bardzo prosta i dobrze opisana w podręcznikach man. Należy jednak należy pamiętać o podstawowej zasadzie: nie wolno ręcznie kasować katalogów cache. Jeśli brakuje nam miejsca na dysku, to należy w pliku konfiguracyjnym zmniejszyć liczbę określającą max przestrzeń dla squid i zrestartować serwer (np. killall -1 squid).

Po uruchomieniu możemy w przeglądarce ustawić adres serwera proxy na komputer z squid
i odpowiedni port.

7.2.3 SOCKS.

Natomiast serwer SOCKS (obecnie SOCKS5) jest serwerem proxy dla ftp, ICQ
i wielu innych aplikacji. Po zainstalowaniu najczęściej umieszcza swój plik konfiguracyjny
w /etc/socks.conf, a jego podstawowa konfiguracja może wyglądać tak:

SET SOCKS5_BINDPORT 192.168.11.1:1080 # określamy adres serwera i numer portu

SET SOCKS5_MAXCHILD 100 # warto określić liczbę procesów potomnych

SET SOCKS5_TIMEOUT 5 # w minutach - maxymalny czas bezczynnego połączenia

interface 149.156.124.11 - eth0 # określenie interfejsów serwera

interface 192.168.11.1 - eth1

auth 192.168.11. - - # skąd można, a skąd nie przyjmować żądania

permit - - 192.168.11. - - - - # i ewentualnie na jakich portach

deny - - 192.168.14. - 21 -

deny - - 192.168.24. - 21 -

deny - - 192.168.25. - 21 -

deny - - 192.168.14. - 8080 -

deny - - 192.168.24. - 8080 -

deny - - 192.168.25. - 8080 -

deny - - - - - - - # wszystkie nie określone żądania odrzucaj

noproxy 192.168. - # nie stosuj proxy dla żądań lokalnych

noproxy 149.156. -

Przed podjęciem decyzji o stworzeniu zapory sieciowej oraz wybraniem jej typu (a może będzie potrzeba więcej zapór ?) należy się zastanowić czy jest to konieczne i jaką politykę będziemy prowadzić. Np. jeśli mamy dwie sieci między wydziałami - czy aby czasem zapora sieciowa nie będzie utrudniała tylko pracy ? Czy jeśli jesteśmy dostawcą usług internetowych (www, mail), to czy będziemy ustawiali każdy adres IP w konfiguracji firewall'a ?

Zapory sieciowe bardziej nadają się do ochraniania sieci prywatnych, w których konieczne jest istnienie wychodzącego połączenia z Internetem, a ruch przychodzący jest niewielki i ściśle kontrolowany. Jeśli nie mamy aż takich potrzeb, możemy zadowolić się rozwiązaniem kontroli dostępu przypominającym w działaniu zapory sieciowe - na przykład TCP Wrappers.

7.3 TCP Wrappers.

TCP Wrappers umożliwia kontrolę sieciową poprzez prosty, ale niezawodny mechanizm. Na hostach bez takiego pakietu inetd uruchamia się podczas startu systemu i sprawdza jakie serwery mają być uruchomione według opisu w pliku /etc/inetd.conf. Każdy wiersz tego pliku określa:

Przykład dla telnet:

telnet stream tcp nowait guest /usr/sbin/telnetd telnetd

Kiedy inetd otrzymuje żądanie od klienta telnet, uruchamia proces telnetd, który na to żądanie odpowiada. W ten sposób tylko jeden demon inetd uruchamia kilkanaście innych serwerów
i działają one tylko wtedy, gdy jest to konieczne. Problem w tym, że takie usługi nie zawsze przeprowadzają kontrolę dostępu. Nie można zatem w prosty sposób kontrolować kto do jakiej usługi ma dostęp. Tu właśnie pomocny jest tcpd (TCP Wrappers).

Program tcpd można wykorzystać do obsługi wszystkich tych usług, które obsługuje inetd,
a do których ma być kontrolowany dostęp. Wtedy, gdy inetd wywołuje serwer, tcpd przechwytuje wywołanie i sprawdza żądanie połączenia. Żądanie porównywane jest
z szeregiem zasad. Jeśli testy zakończą się sukcesem, tcpd uruchamia odpowiedni serwer.
W przeciwnym razie połączenie jest przerywane.

W dystrybucji z zainstalowanym pakietem TCP Wrappers w pliku /etc/inetd.conf linijka
z wywołaniem serwera telnetd może wyglądać tak:

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

I jak widać proces tcpd poprzedza demona telnet.

TCP Wrappers odczytuje zasady dostępu sieciowego z dwóch plików: /etc/hosts.allow (tutaj określone są hosty autoryzowane) i /etc/hosts.deny (tutaj wpisujemy hosty nieautoryzowane). Do konfiguracji tcpd zawartej w tych plikach stworzony został język hosts_options oparty na wzorach określających klienta (nazwa hosta/adres IP, nazwa użytkownika) oraz serwera (nazwa procesu, nazwa hosta/ adres IP).

7.4 Przykłady innych 'ścian ogniowych'.

Do ochrony niewielkiej blokowej, czy akademickiej sieci możemy posłużyć się także jednym z dostępnych darmowych narzędzi do zapór sieciowych dla Linuxa:

Jeśli jednak chcemy ochraniać dużą sieć przedsiębiorstwa a od bezpieczeństwa zależy wiele, to warto skorzystać z oprogramowania komercyjnego, za które ręczy jakaś poważna firma:

8. Rejestrowanie i pliki dziennika.

Rejestrowanie to procedura, dzięki której system operacyjny odnotowuje zachodzące w nim zdarzenia i zachowuje takie zapisy do późniejszej analizy. Rejestrowanie wywodzi się z dobrych nawyków przy pisaniu programów - nawet, gdy tworzymy prosty program, warto posiadać szereg informacji diagnostycznych, takich jak: czy w programie wystąpił błąd,
a jeśli tak to kiedy i dlaczego; identyfikator użytkownika i procesu programu; kto uruchamiał program i po co; czy program wykonuje zadania tak, jakbyśmy chcieli.

W odniesieniu do bezpieczeństwa rejestrowanie służy do tego, by zarejestrować wszelkie zmiany w systemie wskazujące na wystąpienie ataku na system. Pliki dziennika to jedyne namacalne dowody na przestępstwo komputerowe.

Rejestrowanie w systemie Linux odbywa się na poziomie systemu, aplikacji i protokołu. I choć są pewne wyjątki (np. Oprogramowanie firm trzecich), to większość usług linuksowych rejestruje swoje działanie w standardowych, a nawet współdzielonych plikach rejestru
(log files). Większość z nich znajdziemy w katalogu /var/log.

Ponieważ pliki z logami często są dużych rozmiarów i zawierają przeróżne informacje,
w poszukiwaniu tych dla nas interesujących należy posłużyć się odpowiednimi narzędziami.

8.1 lastlog.

lastlog - program do zapisywania procedur logowania użytkowników. Wywołany
z wiersza poleceń formatuje i wyświetla zawartość rejestru logowania /var/log/lastlog: nazę użytkownika, port (terminal) oraz czas ostatniego zalogowania. Domyślnie (bez parametrów) lastlog wyświetli wpisy według identyfikatorów użytkownika (UID), pokazując dane dla wszystkich użytkowników wymienionych w /etc/passwd;

Przykład z serwera centauri.iisg.agh.edu.pl:

Username Port From Latest

root pts/9 centauri Sat Apr 7 10:31:19 +0200 2001

daemon **Never logged in**

bin **Never logged in**

sys **Never logged in**

...

inne konta systemowe

krz pts/0 rdm.polonia.com. Sat Apr 7 10:27:43 +0200 2001

scisz tty1 Mon Apr 2 15:35:32 +0200 2001

lsiwik pts/6 ernie.icslab.agh Sat Apr 7 10:11:37 +0200 2001

oracle tty2 Thu Mar 22 17:54:28 +0100 2001

madej pts/0 jacek.polonia.co Thu Apr 5 16:35:06 +0200 2001

pjozwik tty1 Tue Apr 3 16:38:29 +0200 2001

pawel **Never logged in**

Dane konkretnego użytkownika poznamy dodając do polecenia opcję -u.

lastlog zawiera dane tylko tymczasowe, więc okresowo należy je zapisywać.

8.2 last.

last - wyświetla dane o ostatnim logowaniu użytkownika. Przeszukuje od końca plik /var/log/wtmp (lub inny, określony po parametrze -f) i dostarcza listy wszystkich użytkowników, którzy zalogowali się (i wylogowali) od czasu powstania tego pliku. last dostarcza informacji o nazwie użytkownika, terminalu (lub usłudze), przez który nastąpiło logowanie, adresie IP (lub nazwie hosta) z którego rozpoczęto sesję, dacie i godzinie oraz czasie trwania sesji.

Przykład z ernie.icslab.agh.edu.pl:

gugland ftp pc201.krakow.ppp Sat Apr 7 09:32 still logged in

rzecki pts/23 rdm.polonia.com. Sat Apr 7 09:29 still logged in

gugland pts/21 pc201.krakow.ppp Sat Apr 7 09:27 still logged in

thror pts/21 plus.ds14.agh.ed Sat Apr 7 09:10 - 09:15 (00:04)

thror ftp thror.ds14.agh.e Sat Apr 7 09:10 - 09:10 (00:00)

siwik pts/20 blizzard.ds14.ag Sat Apr 7 09:05 still logged in

mm pts/20 pa197.pradniki.s Sat Apr 7 08:58 - 08:58 (00:00)

skrzynia pts/21 bobo.ds5.agh.edu Sat Apr 7 08:21 - 08:22 (00:00)

Jeśli chcemy tylko dane dotyczące konkretnego użytkownika - wpisujemy jego login jako parametr last. Program posiada również szereg innych pomocnych parametrów.

Oczywiście atakujący zdają sobie sprawę, że pliki z logami /var/log/lastlog
i /var/log/wtmp mogą wskazać sprawcę ewentualnego włamania. Dobry kraker posiada aktualne programy sprzątające (ang. sweepers i cleaners) - programy zmieniające zawartość domyślnych systemów rejestrowania:

Aby najlepiej zabezpieczyć się przed podrabianiem i wymazywaniem wpisów najlepiej skorzystać z dodatkowego narzędzia firmowego, o którym kraker nie będzie wiedział (albo nie będzie się domyślał). Dobrym rozwiązaniem jest też okresowe (co kilka minut) przesyłanie przyrostów logów na inny komputer. Nawet jeśli włamywacz się zorientuje, że logi są redundantne i to na innej maszynie, to będzie musiał albo dokonać dodatkowego włamania, albo ... włamanie zostanie rozpoznane.

8.3 xferlog.

xferlog - program, który zapisuje logi z transferów danych wykonanych przy użyciu FTP. Plik z logami xferlog znajduje się zazwyczaj w /usr/adm. W tym rejestrze gromadzone są następujące informacje: bieżący czas, czas trwania przesyłania, host zdalny (nazwa i adres IP), rozmiar przesyłanego pliku, nazwa pliku, typ transferu (ASCII lub binarny), dodatkowe informacje (czy plik został skompresowany, czy jest to archiwum ta, itp.), kierunek przesyłania, tryb dostępu (anonymous, guest, authorized), nazwa użytkownika, usługa, metoda autoryzacji i identyfikator użytkownika.

8.4 httpd.

Demon httpd przechowuje swoje rejestry najczęściej w katalogu /var/log/httpd/apache i są to dwa pliki:

W pliku access_log znajdziemy wpisy odwiedzin, z których każdy ma konstrukcję: adres IP odwiedzającego, data i czas odwiedzin, polecenie lub żądanie, kod stanu. Kody stanów to liczby, z których dwa najczęściej spotykane (taki kod i odpowiedni komentarz często trafia do naszej przeglądarki) to:

Plik error_log domyślnie zawiera pola: data i czas, typ raportu (błąd), przyczynę błędu, usługę, wykonaną czynność (nie zawsze).

Apache pozwala na dostosowywanie plików dziennika za pomocą dyrektywy LogFormat (znajdziemy ją w plikach konfiguracyjnych apache) i jej domyślna postać to:

LogFormat "%h %l %u %t \"%r\" %s %b"

Co oznacza, że apache zapisze: adres zdalnego hosta, zdalne konto (o ile ident na zdalnym hoście został uruchomiony) zdalnego użytkownika (podobnież), czas w standardowym formacie, pierwsze żądanie klienta, stan oraz ilość przesyłanych bajtów.

Szczegółu pozostałych opcji formatu można znaleźć w manualu.

Obecnie większość demonów tworzy i zapisuje swoje dzienniki. Nie będziemy tu jednak wymieniać i charakteryzować każdego z nich.

8.5 Komunikaty jądra systemu.

Komunikaty jądra systemu obsługiwane są przez dwa demony:

Oba demony zapisują komunikaty w pliku /var/log/messages.

Do konfiguracji programu syslog możemy posłużyć się plikiem /etc/syslog.conf, gdzie określamy zasady jego działania. Plik ten posiada dwa pola, które określają co mamy rejestrować i gdzie dany komunikat ma być wysłany.

W pierwszym polu musimy określić przynajmniej jedną z dwóch wartości:

Typ komunikatu może mieć jedną z następujących wartości:

Można określić większą grupę komunikatów poprzez pominięcie priorytetu komunikatu. Na przykład, poniższa zasada spowoduje wysłanie wszystkich komunikatów jądra na konsolę:

kern.* /dev/console

Druga połowa pierwszego pola pliku syslog.conf określa priorytet, którego zastosowanie nie zawsze jest konieczne. Priorytet musi przyjąć jedną z poniższych wartości:

Jeśli teraz chcemy rejestrować komunikaty o błędach systemu poczty elektronicznej to tworzymy zasadę np.:

mail.err /var/log/mail_err

Czyli: typ to mail, priorytet to err a plik do którego ma się zapisywać informacja to /var/log/mail_err.

Możemy tworzyć zupełnie fantazyjne zasady, mogą też być bardzo liberalne, ale
i bardzo zaostrzone. Możemy wszystkie komunikaty wrzucać do jednego pliku, co spowoduje wielki bałagan i trudności przeglądania takiego pliku. Możemy również wrzucać każdy komunikat umieszczać w innym typ-priorytet pliku, ale dostajemy wówczas: 9 typów * 8 priorytetów = 72 pliki. Wszystko zależy od nas i od charakteru pracy serwera.

Dla podniesienia bezpieczeństwa plików z logami i jeśli chcemy być informowani
w awaryjnych sytuacjach, możemy komunikaty przesyłać mailem na inny komputer tworząc odpowiednią zasadę np.:

*.alert user@inny.komputer

Możemy też przesyłać komunikaty do syslog na innym komputerze, np.:

kern.emerg @inny.komputer

Aby nie tworzyć wielu podobnych wpisów możemy umieszczać po przecinku (bez spacji) wpisy, np.:

mail.*,news.* /var/spool/spooler

Demon syslog pozwala również na odbieranie i zapisywanie komunikatów pochodzących
z własnego programu. Jeśli piszemy w C, to musimy w programie umieścić wpis pliku nagłówkowego syslog.h. Funkcja syslog() tworzy komunikaty, które są przesyłane do syslogd. Szczegóły implementacji znajdziemy w podręczniku man: man 2 syslog

W wolnostojącym komputerze z Linuxem pliki dziennika zwiększają swoją objętość dość powoli. Jeśli jednak w sieci mamy dziesiątki użytkowników, rejestrowanie może zaowocować powstaniem ogromnych plików. Trzeba wtedy pomyśleć o ich archiwizacji lub rotacji. Dobrym rozwiązaniem jest zastosowanie programu logrotate, które jest dobrym i dość rozbudowanym narzędziem. Nie jest on jednak kluczowym punktem w bezpieczeństwie systemu i nie będziemy go tu opisywać.

8.6 Inne narzędzia rejestrujące.

9. Backup i odzyskiwanie danych.

Nawet jeśli zastosujemy najlepsze techniki i narzędzia zabezpieczające nasz system przed włamaniami, spadkami napięcia, to nigdy nie przewidzimy tego co może go zniszczyć. Zawsze może nastąpić awaria, która wtopi wszystkie dotychczasowe dane, ustawienia, konfiguracje systemu. Może się zdarzyć sytuacja, w której nasz źle chłodzony filtr napięcia zrobi małe zwarcie, uszkodzi cały komputer. Może się też zdarzyć pożar, itp. Jednym słowem może nastąpić sytuacja, w której stracimy cały dorobek kilku ostatnich miesięcy. Najgorsze do przeżycia są jednak pomyłki operatora, w rodzju: rm -fr / katalog (między / a katalog jest spacja). Ale również błędy w oprogramowaniu mogą doprowadzić to załamania się systemu i utraty danych.

Warto się przed czymś takim zabezpieczyć. I nie chodzi tu bynajmniej tylko o redundantne dyski, które też mogą być zawodne. Mowa o zespole działań zwiększających redundantność danych naszego systemu.

Istotnym jest, że o kwestii bezpieczeństwa systemu musimy myśleć już podczas budowy sieci. Przede wszystkim, jeśli to tylko możliwe, powinniśmy dążyć do posiadania standardowego sprzętu. Choć Linux w warunkach domowych zadziała niemal na każdym sprzęcie, w warunkach sieciowych trzeba być ostrożnym:

Kolejnym krokiem jest sprecyzowanie zadań jakie nasz serwer będzie spełniał. Instalowanie niepotrzebnych programów nie tylko niepotrzebnie zapełnia przestrzeń na dysku, ale stanowi potencjalne źródło luk w systemie. Zazwyczaj nie będziemy potrzebowali nawet połowy dostępnych w dystrybucji aplikacji, a w szczególności:

Po zainstalowaniu aplikacji instalujemy oprogramowanie Tripwire i tworzymy obraz naszego systemu plików oraz cyfrowe sygnatury wszystkich plików. Możemy posłużyć się innym narzędziem a niezbędnym minimum jest stworzenie sygnatur np. wspominanym wcześniej md5sum.

Jeśli korzystamy z menedżera pakietów (np. rpm), to warto stworzyć kopię zapasową jego pliku historii. W ten sposób szybko będzie można odtworzyć przynajmniej początkową konfigurację bez przeglądania opisów setek pakietów od nowa.

Kolejnym krokiem jest wykonanie pełnej kopii zapasowej systemu na oddzielnym nośniku oraz jej weryfikacja z oryginałem. Kopię zapasową umieszczamy w oddalonym fizycznie miejscu. Takie postępowanie z kopią zapasową może wydawać się nadgorliwością, ale wyobraźmy sobie, że nasz podstawowy dysk padnie. Wystarczy przejść się po kopię zapasową, wymienić dyski i gotowe. Serwer znowu może pracować - odzyskaliśmy w prosty sposób cały system - niestety bez danych.

Do zabezpieczania danych najlepiej jest wykonywać kopie zapasowe na standardowych nośnikach: tradycyjna taśma, dyski optyczne, dyski ZIP, CD-ROMy, dyskietki, itp.

Przy obecnym stanie dostępności i cen wydaje się, że najtaniej i najpewniej jest wykonywać kopie (backup i archiwizację) na płytach CD-ROM. Płyty CD są odporne na wszelkiego rodzaju pola magnetyczne (oczywiście do pewnych granic powyżej których się topi), na zalanie wodą, kawą i dużą cześć różnych odczynników chemicznych. Ze względu na sposób przechowywania informacji (wypalenie fizyczne) są bardzo trwałe.

Z kolei jeśli mamy dostęp do sporych środków finansowych, to warto się zastanowić nad zakupem stacji oraz taśm DAT, które mogą pomieścić cały nasz system (od 2GB - 5GB) na jednej taśmie. Takie rozwiązanie też ma wiele zalet: jeden nośnik z całym backupem trudniej zgubić, możliwe jest przeprowadzenia automatycznego lub zdalnego odzysku. Ponadto takie taśmy można wykorzystywać wielokrotnie.

Zanim przejdziemy do omówienia metod zabezpieczania danych zwróćmy uwagę na pewną terminologię. Często mianem archiwizacji określa się działania mające na celu zabezpieczenie pełne lub przyrostowe (czyli tylko o nowe dane w stosunku do ostatniej archiwizacji) posiadanych danych. Takie zabezpieczenie ma na celu ułatwienie odtworzenia stanu danych w systemie jaki był przed archiwizacją. Archiwizację przeprowadza się stosunkowo często, np. codziennie.

Pod pojęciem backupu kryją się działania, podczas których kopiowany jest cały system (system operacyjny + aplikacje + dane aplikacji) na osobne nośniki i wykonuje się ją nieco rzadziej, np. raz w miesiącu. Backup pozwala odtworzyć cały system, z czego dla niego najważniejsza jest konfiguracja a nie same dane.

Pojęcia archiwizacji i backupu używane są wymiennie i nie będziemy tu zwracać uwagi na trafność ich zastosowania a raczej na charakter przeprowadzanych operacji.

Dobrą strategią jest wykonywanie kopii zapasowych na oddzielnym hoście w sieci. W godzinach nocnych, przy małym natężeniu ruchu w sieci i małym obciążeniu serwera można tworzyć archiwa i przesyłać je do odległego komputera. Można to wykonywać przy pomocy jakiegoś programu, np. cron.

9.1 Prosta archiwizacja.

Zwykle do najprostszej archiwizacji wystarczą nam narzędzia tar i gzip. Program tar wykorzystujemy do skopiowania całej struktury katalogów (lub tej wybranej części) - tak najczęściej rozprowadzane jest oprogramowanie Linuxowe. tar pobiera strukturę katalogów
i pakuje je do jednego pliku o rozszerzeniu *.tar, zwanego często tarball. Po rozpakowaniu takiego pliku wszystkie katalogi i pliki powracają na swoje pierwotne miejsca.

Na przykład jeśli chcielibyśmy zarchiwizować wszystkie dane użytkowników znajdujące się w katalogu i pod katalogach /home. Możemy wykonać to w następujący sposób:

tar cvf home.tar /home

Stworzony zostanie plik home.tar zawierający interesujący całą strukturę katalogu wraz
z plikami.

Jeśli chcielibyśmy przeprowadzić archiwizację całego systemu, to:

tar cvf system.tar /

Nie jest to jednak zalecany sposób wykonywania kopii systemu. Utworzony plik będzie miał ogromne rozmiary.

Spośród najważniejszych opcji programu tar należy wymienić (znak '-' przed zbiorem opcji nie jest wymagany):

Informacje o pozostałych opcjach można uzyskać z podręcznika manual: man tar

Ponieważ program tar kopiuje całe katalogi wraz z plikami, to archiwum wynikowe zajmuje tyle przestrzeni dyskowej (z dokładnością do niewykorzystanych klastrów) co oryginalna struktura katalogów z plikami, musimy archiwum to poddać kompresji. Najwygodniej wykonuje się to poleceniem gzip. Jeśli chcielibyśmy spakować utworzony wcześniej home.tar, to wykonujemy to poprzez: gzip home.tar. Plikiem wynikowym będzie home.tar.gz. Zwykle nie używa się jakichś szczególnych opcji, a na ich temat możemy poczytac w man gzip.

Jeśli mamy nasze spakowane archiwum home.tar.gz, to możemy spróbować odtworzyć jego zawartość:

Najpierw należy je rozpakować poleceniem: gunzip home.tar.gz

A następnie roztarować: tar xvf home.tar

Wygodnie jest skorzystać z połączenia obu programów tak, aby jednym poleceniem tworzyć spakowane archiwum i podobnie je odtwarzać. Tworzenie archiwum możemy wykonać to programem tar z opcją 'z':

tar cvfz home.tar.gz /home

A jego odtwarzanie:

tar xvfz home.tar.gz

Należy pamiętać, ze program tar odtwarzane archiwum umieszcza w miejscu w którym aktualnie go wywołujemy. To znaczy, że jeśli przeniesiemy się do katalogu /tmp i tam wykonamy odtwarzanie programem tar, to tam zostanie umieszczony nasz /home (czyli /tmp/home/...).

9.2 Narzędzie archiwizujące: cpio.

cpio (ang. copy in, copy out) tworzy archiwa plików i katalogów. Do przeprowadzenia podstawowej archiwizacji wydajemy polecenie:

ls / | cpio -o > [urzadzenie]

Polecenie to tworzy listę wszystkich plików i katalogów i przekazuje ją potokiem do cpio. Program cpio kopiuje otrzymane informacje na wyjście standardowe, a to przekierowane jest do określonego urządzenia. cpio przyjmuje szereg różnych opcji z wiersza poleceń, z których najważniejsze mogą być:

Pozostałe opcje można znaleźć w man cpio.

9.3 Planowanie archiwizacji: dump.

Generalnie archiwizację możemy podzielić na dwa rodzaje:

dump potrafi sam badać pliki w systemie plików i określić, które z nich mają zostać zarchiwizowane. Pliki te kopiowane są następnie na określone urządzenie.

Najpierw należy poinformować program, który system plików będziemy archiwizować, np.:

/sbin/dump 0uf /dev/nrst1 /dev/hda2

co oznacza mniej więcej:

I program wykona kopię drugiej partycji pierwszego dysku twardego. dump po wykonaniu zadania zapisze rezultat w pliku /etc/dumpdates - będzie to określenie dysku, który został zarchiwizowany, poziom archiwizacji i data archiwizacji. Później na podstawie tych wpisów dump będzie wykonywał dalsze zadane archiwizacje.

dump przyjmuje wiele parametrów, z których najistotniejsze to:

Archiwizowanie dump można poddać kompresji. Jeśli na przykład chcemy wykonać pełną archiwizację /home, kopię poddać kompresji, a następnie wszystko wysłać do napędu taśmowego, wydajemy polecenie:

dump 0unf - /home | gzip -c > /dev/nrst1/home.gz

9.4 Odtwarzanie archiwizacji wykonanych przez dump: restore.

Program restore działa po prostu odwrotnie do dump. Odtwarza system z archiwum pełnego i dopisuje do niego zmiany zapisane w archiwach przyrostowych. Z obu rodzajów archiwów można odczytać pojedyncze pliki lub drzewa katalogów.

Składnia polecenia zależy od tego, co zamierzamy zrobić. Polecenie w najprostszej postaci wyglądałoby następująco:

restore rf /dev/nrst1

Czyli program odzyskuje (opcja r) system plików (opcja f) z /dev/nrst1 i kopiuje go do bieżącej hierarchii katalogów. restore, podobnie jak dump, oferuje bardzo dużą ilość parametrów. Niektóre z nich:

9.5 Inne pakiety archiwizujące.

Na zakończenie tematu archiwizacji zwróćmy jeszcze uwagę na najistotniejsze aspekty tego zagadnienia:

7


Wyszukiwarka

Podobne podstrony:
Bezpieczeństwo systemów komputerowych
Bezpieczeństwo systemów komputerowych
BSI, Semestr 8, Bezpieczeństwo systemów komputerowych
Polityka bezpieczenstwa w systemie komputerowym, Polityka Bezpieczeństwa w Systemach Komputerowych
Bezpieczenstwo systemów komputerowych 3
Bezpieczeństwo systemów komputerowych w świetle prawa
Bezpieczeństwo systemów komputerowych
Bezpieczeństwo systemów komputerowych
Bezpieczeństwo systemów komputerowych 2
Praca Dyplomowa BezpieczeĹ stwo SystemĂłw Komputerowych A Hakerzy, prace doktorskie, magisterskie, P
System bezpieczeństwa dla komputerów osobistych ( DACS for Windows 95 Data Access Control System)
10 Reprezentacja liczb w systemie komputerowymid 11082 ppt
wyklad 2012 10 25 (Struktury systemów komputerowych)
Abstrakcyjne wyobrażenie elementów systemu komputerowego
Podstawy Informatyki Wykład V Struktury systemów komputerowych

więcej podobnych podstron