2005.01_Bezpieczne łączenie się z Internetem_[Bezpieczenstwo].pdf

bezpieczeństwo

Bezpieczne

łączenie się

z Internetem

Piotr Machej

J eśli ktoś jeszcze wierzy, że w dzisiej-

Rysunek 1. Na stronach serwisu SANS

możemy znaleźć obszerne wskazówki

dotyczące wykrywania intruzów

Planowanie zabezpieczeń

Absolutnie nie powinniśmy podłączać

do Internetu komputera, który nie został

jeszcze zabezpieczony. Może wydawać

się nam, że jeśli podłączymy się tylko

na chwilkę, to nic się nie stanie. Jest to

jednak bardzo złudne wrażenie. Włamy-

wacze bardzo często automatyzują swoją

pracę, uruchamiając skrypty okresowo

sprawdzające adresy sieciowe kompu-

terów. Poszukują w ten sposób maszyn

wrażliwych na znane im metody ataków

(np. posiadających bardzo proste hasła).

Może zdarzyć się, że nasz system zostanie

spenetrowany już w minutę po zalogowa-

niu do sieci. Z tego powodu jak najwię-

cej czynności zabezpieczających powin-

niśmy dokonać jeszcze przed skorzysta-

niem z Internetu.

Zanim zabierzemy się za umacnia-

nie zabezpieczeń, dobrze jest dokładnie

zastanowić się, co chcemy osiągnąć. Czy

chcemy zrobić z naszego komputera nie-

zdobytą twierdzę? A może tylko chcemy

ochronić nasze zdjęcia z igraszek na łonie

natury? Istotne jest też, czy będziemy

chcieli udostępniać jakieś zasoby innym

użytkownikom Internetu. Jeśli kompu-

ter będzie przeznaczony dla wielu anoni-

mowych użytkowników (np. jako anoni-

mowy serwer FTP ), to zastosujemy inne

zabezpieczenia niż wtedy, gdy do kom-

putera będziemy chcieli mieć dostęp

tylko my, razem z wybranymi kolegami.

Dobre określenie naszych celów

i potrzeb pozwoli nam lepiej wykorzy-

stać zawarte w tym artykule informacje.

Mając ciągle na myśli nasz cel, z łatwo-

ścią wybierzemy zabezpieczenia, które

musimy zastosować, i pominiemy te,

z których możemy (lub nawet powinni-

śmy) zrezygnować.

Na płycie CD/DVD

Na płycie CD/DVD znajduje się

oprogramowanie omawiane

w artykule.

Wykorzystywane usługi

Generalna zasada mówi, aby uruchamiać

tylko niezbędne usługi. Tak naprawdę

powinniśmy posunąć się nieco dalej i w

ogóle nie instalować niepotrzebnego opro-

gramowania. Praktycznie każda z dystry-

bucji podczas instalacji pozwala nam na

wybór pojedynczych pakietów, z których

chcemy korzystać. Warto poświęcić trochę

czasu na lekturę opisów poszczególnych

pakietów i wybranie tylko tych, które na

pewno nam będą potrzebne.

Zysk z takiego postępowania jest

podwójny. Po pierwsze, oszczędzamy

miejsce na dysku. Po drugie, zmniejsza-

my liczbę zainstalowanego oprogramo-

wania. Dzięki temu łatwiej nam będzie

kontrolować zmiany w systemie, a w

dodatku możemy uniknąć instalacji pro-

gramów znanych z problemów z bez-

pieczeństwem. Warto zastanowić się

nad tym, który program wykorzystamy

do realizacji konkretnego celu. Przykła-

dowo, jeśli jest nam potrzebny serwer

26 styczeń 2005

szych czasach jego komputer podłą-

czony do Internetu nie jest zagrożo-

ny, to powinien natychmiast zdjąć

różowe okulary. Korzystając z ogólno-

światowej pajęczyny , nie jesteśmy samot-

ni – wraz z nami jest tam wiele osób

o bardzo różnych charakterach i potrze-

bach. Dlatego warto podjąć środki ostroż-

ności. Pozwoli nam to żeglować po Inter-

necie ze spokojem, że nasze dane nie są

łatwe do wykradzenia lub zniszczenia.

bezpieczny internet

bezpieczeństwo

pocztowy, możemy zainstalować Send-

maila (dosyć topornego w konfigura-

cji i mającego w przeszłości sporo pro-

blemów z bezpieczeństwem) lub szyb-

kiego i łatwego w konfiguracji (a przy

tym bezpiecznego) Postfiksa . Również w

przypadku pozostałego oprogramowania

mamy różne alternatywy, nawet jeśli nie-

koniecznie są one dołączone do dystry-

bucji. Im bardziej zależy nam na bezpie-

czeństwie naszego systemu, tym więcej

wysiłku powinniśmy włożyć w zainstalo-

wanie bezpiecznych aplikacji.

Hasła użytkowników

Oglądaliście film Hakerzy ( Hackers )?

Pomimo całej jego naiwności, było w nim

trochę prawdy. Szczególnie w jednym miej-

scu, gdy pada pytanie o najpopularniejsze

hasła wykorzystywane przez użytkowni-

ków komputerów. Odpowiedzią były: love,

secret, sex i god . I taka jest prawda – wiele

osób lekceważy znaczenie haseł i wybie-

ra pierwsze z brzegu. No bo przecież, kto

się domyśli, że wybrałem hasło misiek ? A

przynajmniej łatwo mi je będzie zapamię-

tać. I rzeczywiście. Ale równie łatwo przyj-

dzie je odgadnąć włamywaczowi.

Zakładając proste hasło ułatwiamy mu

życie. Nie musi się męczyć z wyszukiwa-

niem luk w naszym systemie i analizo-

waniu sposobów włamania do niego. Po

prostu uruchamia program sprawdzający

po kolei hasła ze słownika i idzie sobie na

herbatę. A gdy wróci, nasz komputer nie

ma już dla niego tajemnic. Ustawiajmy więc

hasła trudne do odgadnięcia, ale nadal

łatwe do zapamiętania. Warto też samemu

stosować różne programy do łamania haseł

– właśnie w celu sprawdzenia, na ile nasze

hasła są trudne do złamania. Reguły te

dotyczą nie tylko haseł do kont na naszym

komputerze. Każdy z użytkowników powi-

nien w ten sposób traktować również inne

hasła – do skrzynki pocztowej, do portalu

internetowego czy jakiejś gry sieciowej.

Pamiętajmy też o tym, aby nigdzie

(podkreślam – nigdzie!) nie używać takie-

go samego hasła, jakie broni dostępu do

konta użytkownika root . Co do innych

haseł, to często trudno uniknąć ich dublo-

wania – choćby ze względu na ogranicze-

nia naszej pamięci. Należy jednak podcho-

dzić do tego z rozwagą. Jaki bowiem jest

sens zakładania mocnego hasła na nasze

konto, jeśli używamy go również w kilku

serwisach internetowych, gdzie jest ono

przechowywane otwartym tekstem? To

prawdziwe zaproszenie dla włamywacza.

Oczywiście, jeśli nie mamy urucho-

mionego serwera SSH , FTP czy Telnet

(o tym ostatnim lepiej zapomnieć – nie

instalujemy go i nie uruchamiamy), to

intruz próbujący dostać się do nas z Inter-

netu niewiele skorzysta z naszego hasła.

Lepiej być przezornym – może kiedyś

uruchomimy serwer, albo zaprosimy do

siebie znajomego. Warto mieć wtedy

mocne, trudne do złamania hasła.

Rysunek 2. Część z tych nasłuchujących

usług z pewnością można wyłączyć

ni użytkownicy, warto zabezpieczyć się

dodatkowo. Po pierwsze, powinniśmy

odpowiednio skonfigurować zaporę sie-

ciową, aby można było logować się tylko z

określonych komputerów. Nie zawsze jest

to możliwe (szczególnie, jeśli dużo podró-

żujemy i logujemy się z różnych miejsc).

Po drugie, możemy w ogóle uniemożliwić

włamywaczom atak na hasła. Jest to moż-

liwe dzięki temu, że SSH pozwala na auto-

ryzację za pomocą pary kluczy. Jeśli każdy

z użytkowników mających dostęp do

naszego komputera będzie dobrze pilno-

wał swojego klucza prywatnego, a klucze

publiczne będą umieszczone u nas, to spo-

kojnie możemy wyłączyć obsługę zwy-

kłych haseł. Dokonujemy tego wstawiając

w pliku /etc/ssh/sshd_config linię o treści:

Uruchamianie usług

Jak już powiedziałem, powinniśmy uru-

chamiać tylko niezbędne usługi. Ale skoro

zbędnych nawet nie zainstalowaliśmy, to

o co chodzi? Otóż może zdarzyć się, że

nie ze wszystkich usług będziemy korzy-

stać bez przerwy. Opiszę tu znany mi

przykład. Mamy komputer, który kiedyś

był podłączony do Internetu za pośred-

nictwem sieci lokalnej, w której działały

również komputery z systemem Windows .

Do współdzielenia plików była wykorzy-

stywana na tym komputerze Samba . Po

jakimś czasie komputer został odłączony

od sieci lokalnej i przyłączony do Interne-

tu bezpośrednio. Samba pozostała zain-

stalowana, gdyż przydaje się do współ-

dzielenia plików z systemem Windows 98,

uruchamianym pod kontrolą VMWare .

Ponieważ ta funkcjonalność jest wykorzy-

stywana okazjonalnie (raz na tydzień lub

rzadziej), więc nie ma uzasadnienia dla

uruchamiania Samby przy starcie systemu.

Dlatego też tego typu usługi powinny być

wyłączone. Uruchamiamy je tylko wtedy,

gdy są nam potrzebne.

Sposób wybrania usług, które mają

być uruchamiane przy starcie, zależy

od dystrybucji. W przypadku dystrybucji

pochodzących od Red Hat (na przykład

Fedora i Aurox ) należy usunąć lub dodać

odpowiednie łącza symboliczne w kata-

logu /etc/rc.d/ . W innych dystrybucjach

nazwa katalogu może być inna. Można

również wykorzystać do tego celu narzę-

dzie ntsysv . Z kolei usługi uruchamiane

przez superserwer Xinetd można wyłą-

czyć zmieniając opcję disable w plikach

umieszczonych w katalogu /etc/xinetd.d/ .

Wyniki naszych działań można obserwo-

wać wpisując polecenie netstat -nlutp .

Wyświetli ono wszystkie porty TCP i

UDP , na których nasłuchują jakieś pro-

gramy. Oprócz tego, poznamy nazwy

tych programów.

PasswordAuthentication no

Po zrestartowaniu serwera SSH użytkownik

próbujący zalogować się bez odpowiednie-

go klucza powinien zobaczyć komunikat:

Permission denied (publickey,keyboard-

interactive) . Należy więc uważać, aby przy-

padkiem nie odciąć sobie dostępu do ser-

wera stojącego na drugim końcu kraju.

W ten sam sposób możemy sami

łączyć się ze zdalnymi serwerami – za-

miast wykorzystywać hasła (choćby prze-

syłane przez SSH ), korzystajmy z pary

kluczy. Najpierw musimy je wygenerować.

Zaczynamy od wydania polecenia:

ssh-keygen -t rsa

Zostaniemy zapytani o nazwę pliku,

w którym ma być umieszczony klucz pry-

watny, a następnie o hasło. Tak, o hasło. Z

zaletami i wadami wprowadzenia tu hasła

możemy zapoznać się w ramce Klucze z

hasłem czy bez? – na tej podstawie zdecy-

dujemy, czy wciśniemy tu klawisz [ Enter ],

czy też jednak wpiszemy hasło. W wyniku

powinniśmy uzyskać dwa pliki. Pierwszy z

nich (domyślnie ~/.ssh/id_rsa ) to klucz pry-

Bez haseł w SSH

Jeśli mamy uruchomiony serwer SSH , do

którego powinni mieć dostęp tylko wybra-

www.lpmagazine.org

bezpieczeństwo

cat id_rsa.pub >> .ssh/authorized_keys

chmod 600 authorized_keys

Testowanie haseł

W większości nowszych dystrybucji pod-

czas wprowadzania hasła jest prze-

prowadzana jego wstępna kontrola

(np. z wykorzystaniem systemu PAM ),

ale czasami system ogranicza się tylko do

sugestii, że wprowadzane hasło nie speł-

nia odpowiednich norm (np. jest za krótkie

lub zbyt oczywiste). Tak czy inaczej, jest to

tylko wstępne rozpoznanie. Aby się prze-

konać, czy na pewno w naszym systemie

hasła są trudne do złamania, musimy sko-

rzystać z innych narzędzi – łamaczy haseł.

Jednym z takich programów jest John

the Ripper . Możemy go pobrać ze strony

http://www.openwall.com/john/ . Po jego

zainstalowaniu (zgodnie ze wskazówka-

mi umieszczonymi w pliku doc/INSTALL )

wykonujemy kopię pliku /etc/shadow

i umieszczamy ją w jakimś bezpiecznym

katalogu (pamiętajmy, aby przypadkiem

nie udostępnić tego pliku niepowołanym

osobom). Teraz wystarczy uruchomić pole-

cenie john shadow (zakładając, że kopia

pliku /etc/shadow znajduje się w bieżącym

katalogu). Jeśli programowi uda się odgad-

nąć hasło, wyświetli je na ekranie wraz z

nazwą użytkownika. Ponieważ obliczenia

mogą trwać bardzo długo, warto czasem

wcisnąć dowolny klawisz w celu sprawdze-

nia, czy program nadal działa – zostanie

wyświetlony jego status. W dowolnej chwili

możemy przerwać jego pracę kombinacją

[ Ctrl ]+[ c ], a następnie wznowić poleceniem

john -restore .

Odgadnięte hasła, oprócz wyświe-

tlenia na ekranie, są zapisywane

w pliku john.pot , umieszczonym w kata-

logu, gdzie znajduje się program john .

Możemy je wyświetlić poleceniem john

-show shadow (gdzie shadow wskazuje na

naszą kopię pliku /etc/shadow ).

Jeśli chcemy zwiększyć szanse na

wykrycie słabych haseł, powinniśmy

pobrać z sieci pliki ze słownikami. Przykła-

dowy plik z listą słów w różnych językach

jest do pobrania ze strony domowej John

the Ripper , a jego znacznie rozszerzoną

wersję można zamówić za odpowiednią

opłatą. Inne zestawy haseł można zna-

leźć pod adresem ftp://ftp.ox.ac.uk/pub/

wordlists/ . Możemy je później wykorzystać

wydając polecenie john -w=words.lst

shadow , gdzie world.lst jest pobranym pli-

kiem ze słownikiem.

Warto też zapoznać się z plikiem doc/

EXAMPLES , gdzie podane są inne cieka-

we sposoby wywołania programu John

the Ripper .

Należy upewnić się jeszcze, czy na zdal-

nym serwerze jest włączona obsługa

kluczy i że wykorzystywany jest wła-

śnie ten plik ze spisem kluczy. W pliku

/etc/ssh/sshd_config powinny znajdować

się następujące linie:

Rysunek 3. John the Ripper to tylko

jeden z wielu programów umożliwiających

testowanie siły haseł

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

watny, którego należy strzec niczym oka

w głowie. Nikt poza nami nie powinien

mieć prawa do jego odczytu, a najlepiej,

jeśli przechowywać go będziemy tylko na

zabezpieczonej dyskietce. Drugi plik (do-

myślnie ~/.ssh/id_rsa.pub ) to klucz publicz-

ny, którego nie musimy chronić – każdy

może mieć do niego dostęp.

Teraz czas skopiować klucz publicz-

ny na nasze konto na zdalnym serwerze.

Gdy to zrobimy, logujemy się na to konto.

Musimy upewnić się, że mamy tam katalog

~/.ssh/ . Jeśli nie, tworzymy go poleceniami:

Teraz już możemy opuścić to konto ( exit )

i spróbować zalogować się ponownie.

Tym razem powinien powitać nas napis:

Enter passphrase for key z podaną ścież-

ką do klucza prywatnego. Po wpisaniu

hasła, jakiego użyliśmy przy tworzeniu

klucza, zostaniemy zalogowani na nasze

konto. Oczywiście, jeśli zdecydowaliśmy

się nie chronić naszego klucza hasłem, to

zostaniemy zalogowani bez pytania.

Gdy kiedyś zdecydujemy się zmie-

nić hasło do naszego klucza prywatnego,

możemy to zrobić poleceniem ssh-keygen

-c -f .ssh/id_rsa .

mkdir .ssh/

chmod 700 .ssh/

Kontrola integralności

systemu

Pomimo wszelkich zabezpieczeń, jakie

mogliśmy stworzyć, szczególnie zdespe-

rowany intruz, prędzej czy później, jest

w stanie dostać się do naszej twierdzy.

Musimy być świadomi, że jedyną w miarę

skuteczną formą ochrony naszego kom-

putera jest odłączenie go od sieci i wsta-

wienie do szafy pancernej. Jeśli jednak

chcemy, aby nasz komputer był podłą-

czony do Internetu, to musimy liczyć się

z ewentualnym włamaniem.

W takim przypadku najważniej-

sze jest, abyśmy się o tym dowiedzieli.

Ponieważ intruz zazwyczaj będzie próbo-

wał ukryć swoją obecność w systemie, a

następnie uzyskać jak najwięcej informa-

cji, prędzej lub później spróbuje podmie-

nić jakiś kluczowy plik systemowy. Może

tego dokonać na przykład w celu wykra-

dzenia hasła. Jednym z najlepszych spo-

sobów na wykrycie podobnych działań

jest kontrolowanie integralności syste-

mu. Polega to na tym, że (zaraz po insta-

lacji systemu) tworzymy bazę zawierającą

informacje o istotnych plikach w systemie.

Bazę tą przechowujemy w miejscu niedo-

stępnym dla włamywacza (np. na płycie

CD ). Później pozostaje nam okresowo

kontrolować zgodność plików ze stanem

Teraz pozostaje nam dodać klucz publicz-

ny do spisu kluczy, które mogą być

wykorzystywane do łączenia się z tym

kontem:

Zbędne usługi

Jeśli mamy wątpliwości, które usługi

powinny być wyłączone, zapoznajmy się

z poniższym spisem: chargen , chargen-

udp , daytime , daytime-udp , echo , echo-

udp , inger , imap , imaps , innd , ipop2 ,

ipop3 , named , netfs , ntalk , ntpd , pop3s ,

swat , talk , time , time-udp .

Zawiera on te usługi, których nie

powinniśmy włączać, jeśli nie są nam

absolutnie potrzebne. Nie jest to spis kom-

pletny – oprócz podanych usług, możemy

mieć zainstalowane inne programy, któ-

rych nie powinniśmy włączać bez potrze-

by, jak choćby różne serwery FTP ( wu-ftpd ,

vsftpd ) czy wszelkie usługi typu rsh , rexec ,

rcp , rlogin i inne z grupy usług o nazwach

zaczynających się literą r (możemy je spo-

kojnie zastąpić programem ssh ).

Jeśli zaszłaby konieczność włącze-

nia jednej z wymienionych usług, w miarę

możliwości powinniśmy wybierać wersję

bezpieczniejszą. Przykładowo, zamiast

imap powinniśmy wybrać szyfrowaną

wersję imaps , a zamiast ipop3 – pop3s .

zapisanym w bazie. Oczywiście, jeśli sami

dokonamy zmian w plikach (na przykład

ze względu na aktualizację oprogramowa-

styczeń 2005

bezpieczny internet

bezpieczeństwo

Klucze z hasłem czy bez?

Podczas tworzenia kluczy musimy zdecy-

dować, czy nasz klucz prywatny będzie

chroniony hasłem, czy nie. Można się

zastanawiać, co się zyskuje, zamienia-

jąc jedno hasło (do systemu) na drugie

(do klucza). Już odpowiadam – bardzo

dużo. Przede wszystkim, ewentualny wła-

mywacz musiałby zdobyć zarówno nasze

hasło, jak i klucz prywatny, co znacznie

utrudnia mu zadanie. Tym bardziej, że

hasło chroniące klucz nie jest przesyłane

przez sieć. W dodatku, możemy wykorzy-

stać ten sam klucz do łączenia się z wielo-

ma serwerami – a więc możemy korzystać

w tym przypadku z jednego hasła.

A jeśli jednak zdecydujemy się na

stworzenie klucza bez hasła? Możemy tak

zrobić, ale wtedy musimy jeszcze bardziej

chronić nasz klucz prywatny. Jeśli komuś

uda się uzyskać do niego dostęp, to będzie

mógł połączyć się bez problemów wszę-

dzie tam, gdzie z tego klucza korzystali-

śmy. Dlatego jeśli tylko do naszego kom-

putera ma dostęp więcej osób, to lepiej

założyć hasło, a w każdym razie zdawać

sobie sprawę z niebezpieczeństwa.

ustawienia domyślne powinny wystarczyć,

lecz w razie potrzeby można je zmodyfi-

kować. Plik konfiguracyjny posiada dosyć

obszerne i czytelne komentarze.

np. specjalnie przygotowanej dystrybu-

cji uruchamianej z płyty CD . Dzięki temu

możemy mieć pewność, że włamywacz

nie mógł zmodyfikować naszego progra-

mu, ani żadnej części systemu, od której

on zależy.

Musimy zdawać sobie sprawę z tego,

że Afick i jemu podobne programy nie

uchronią nas przed włamaniem do sys-

temu. Ich zadaniem jest jedynie dać nam

znać, że włamanie miało miejsce. Nie

należy w tej mierze polegać tylko na inte-

gralności systemu – należy również kon-

trolować dzienniki systemowe (logi), jak

i uruchomione usługi. Warto też okreso-

wo wykonywać kopię ważnych dla nas

danych. Dzięki temu nie utracimy ich, ani

z powodu jakiegoś wandala, ani też ze

względu na przypadkową awarię sprzętu.

Wykrywanie zmian w plikach

W celu sprawdzenia, czy nie nastąpiły

zmiany w plikach systemowych, urucho-

miamy polecenie /usr/bin/afick.pl -k

(lub /usr/bin/afick.pl --compare ). Spo-

woduje to ponowne przeanalizowanie

wszystkich plików i porównanie informa-

cji o nich z zawartymi w bazie. Ewentual-

ne różnice zostaną wyświetlone na ekra-

nie. Oczywiście, możemy tego dokonać

również w interfejsie graficznym (wci-

skając przycisk compare ) lub w module

Webmina (w sekcji run Afick , zaznacza-

jąc w polu action wartość compare i wci-

skając przycisk Run Afick ).

W przypadku wykrycia zmian w pli-

kach, nie powinniśmy od razu pani-

kować. Najpierw upewnijmy się, czy

sami nie dokonaliśmy zmian (mogli-

śmy zapomnieć uaktualnić bazę). Może

okazać się również, że przechowujemy

w bazie informacje o plikach zmieniają-

cych się dosyć często, a niezbyt istotnych

– w takim przypadku należy poprawić

konfigurację i ponownie zainicjalizować

bazę poleceniem /usr/bin/afick.pl -i

( init w przypadku interfejsu graficznego

i modułu Webmina ).

Jeśli zamierzamy wprowadzić zmiany

w systemie plików (np. uaktualnić oprogra-

mowanie), powinniśmy najpierw upewnić

się, że pliki są nienaruszone. Następnie

możemy dokonać niezbędnych zmian,

a później zaktualizować bazę poleceniem

/usr/bin/afick.pl -u ( update w przypad-

ku interfejsu graficznego i modułu Web-

mina ). Polecenie to wyświetli nam wpro-

wadzone zmiany, a w bazie umieści infor-

mację o nowych plikach.

Jeśli chcemy dokładnie wiedzieć, jakie

zmiany zaszły podczas instalacji oprogramo-

wania, to należy uruchomić polecenie

update zarówno przed, jak i po instalacji.

Zapora sieciowa

Jednym z najważniejszych zabezpieczeń

naszego komputera jest zapora sieciowa,

zwana też ścianą ogniową ( firewall ). Jeśli

prawidłowo ją skonfigurujemy, będzie

chroniła porty naszego komputera przed

intruzami, udostępniając je tylko wybra-

nym osobom. Oczywiście, my będzie-

my mogli korzystać z Internetu bez ogra-

niczeń.

W przypadku aktualnych dystrybucji

Linuksa, najczęściej do filtrowania pakie-

tów jest wykorzystywany program IPTales .

Z reguły najlepszą metodą tworzenia

zapory sieciowej jest przyjęcie zasady, że

blokujemy wszystkie pakiety z wyjątkiem

tych, które rzeczywiście chcemy przepu-

ścić. Zasada jest słuszna, lecz w niektórych

przypadkach może nam sprawić nieco kło-

potu. Wyobraźmy sobie przykładowo, że

chcemy udostępniać użytkownikom Inter-

netu serwer SSH , WWW , FTP , a w dodat-

ku pragniemy dzielić się plikami z użyciem

BitTorrenta . W takiej sytuacji może okazać

się, że mniej wysiłku będzie nas koszto-

wać stworzenie zapory, która będzie bro-

niła dostępu tylko do wybranych portów

nia), to bazę musimy również uaktualnić.

Jednym z programów pozwalających na

kontrolowanie integralności systemu jest

Afick ( Another File Integrity Checker ).

Ponieważ nie jest on zazwyczaj dołą-

czany do dystrybucji Linuksa, musimy

go pobrać ze strony domowej ( http:

//afick.sourceforge.net/ ) lub z płyty dołą-

czonej do pisma. Jego instalacja nie spra-

wia problemu, a w przypadku instalacji

pakietu RPM od razu zostanie zainicja-

lizowana baza. Na stronie domowej pro-

jektu możemy pobrać interfejs graficzny,

ułatwiający obsługę programu, a także

spełniający to samo zadanie moduł do

Webmina . Z tych dwóch możliwości oso-

biście polecam raczej moduł do Webmi-

na – po instalacji dostępny jest w sekcji

System pod nazwą Another File Integri-

ty Checker .

Koniguracja Aicka

Główny plik konfiguracyjny programu

Afick to plik /etc/afick.conf . Możemy w

nim określić ścieżki do bazy danych, histo-

rii i archiwum. Oprócz tego, możemy usta-

wić inne opcje konfiguracyjne, jak również

wykluczyć z magazynowania w bazie pliki

o określonych końcówkach (lub przedrost-

kach) nazw. Plik ten zawiera również spis

katalogów, o których informacje są zapisy-

wane w bazie. W większości przypadków

Kilka uwag

Sprawdzanie integralności systemu nie

ma większego sensu, jeśli włamywacz

ma dostęp do konfiguracji i bazy danych.

Warto plik konfiguracyjny i bazę prze-

chowywać np. na płycie CD , uaktualnia-

jąc ją w razie potrzeby.

Optymalnym rozwiązaniem jest uru-

chamianie programu Afick z osobne-

go, bezpiecznego systemu operacyjnego,

Rysunek 4. Konigurację Aicka możemy

zmienić także z użyciem Webmina

www.lpmagazine.org

bezpieczeństwo

(np. poczty czy Samby ). Należy pamię-

tać, że tak zbudowana zapora nie będzie

w stanie zablokować możliwości łączenia

się z naszym serwerem, jeśli zostanie na

nim zainstalowana jakaś tylna furtka ( back-

door ). Wybór metody tworzenia zapory

zależy więc tylko od naszych chęci i umie-

jętności.

Podczas projektowania zapory pamię-

tajmy o tym, aby zablokować możli-

wość łączenia się z naszym kompute-

rem z maszyn o adresach sieci lokalnej za

pośrednictwem interfejsu łączącego nas

z Internetem. Zapobiegnie to przynajm-

niej części prób ataków przez podszywa-

nie ( spoofing ).

Jeśli nie odpowiada nam ręczne wpi-

sywanie regułek, możemy skorzystać

z któregoś z interfejsów graficznych.

Jednym z ciekawszych jest Firewall Buil-

der , którego wersja 2.0.2 była niedawno

opisywana w Linux+ . Program ten można

pobrać ze strony domowej projektu ( http://

www.fwbuilder.org/ ) lub z płyty dołączo-

nej do gazety.

łów dostępnych z CPAN : Net::RawIP , Net:

:PcapUtils i NetPacket . Możemy je zainsta-

lować poleceniem perl -MCPAN -e 'in-

stall Net::RawIP' (odpowiednio zmie-

niając nazwę modułu). Na komputerze,

gdzie mamy zainstalowaną zaporę siecio-

wą, należy uruchomić polecenie ./ftestd

-i eth0 (gdzie eth0 to nazwa interfejsu

łączącego nas z siecią). Spowoduje to uru-

chomienie sniffera nasłuchującego pakie-

tów wysyłanych przez klienta. Klienta naj-

lepiej uruchomić na komputerze znajdu-

jącym się bezpośrednio za zaporą siecio-

wą – służy do tego polecenie ./ftest -f

ftest.conf . Najpierw jednak należy przy-

gotować odpowiedni plik konfiguracyjny,

w którym wskażemy, jakie testy mają być

wykonywane. Przykładowy plik ftest.conf

jest dosyć dobrze opisany, więc nie powin-

niśmy mieć problemów z dostosowa-

niem go do własnych potrzeb. Zwróćmy

uwagę, że możemy korzystać zarówno

z pojedynczych pakietów, np. 192.168.0.5:

1025:192.168.0.1:21:A:TCP:0 , jak i z symu-

lowania połączeń: connect=192.168.0.5:

1025:192.168.0.1:22:AP:TCP:0 . Każdy test

powinniśmy kończyć sygnałem zatrzy-

mania: stop_signal=192.168.0.5:80:

192.168.0.1:1025:S:TCP:0 . Ważne, aby ten

ostatni pakiet na pewno przeszedł przez

zaporę. W innym przypadku, jeśli na czas

testów zmienialiśmy ustawienia TTL , to w

przypadku przerwania działania skryptu

przed otrzymaniem sygnału stop , będzie-

my musieli przywracać ustawienia ręcz-

nie. Po zakończeniu testu należy skopio-

wać pliki ftest.log z klienta i ftestd.log z ser-

wera w jedno miejsce, a następnie wyko-

nać polecenie ./freport ftest.log fte-

std.log . W jego wyniku otrzymamy zesta-

wienie pakietów, które przeszły lub zostały

zablokowane przez zaporę sieciową.

Podczas testowania zapory powinni-

śmy pamiętać, aby sprawdzić ją bardzo

dokładnie. Jeśli w jakiejś regułce mamy zde-

finiowany zakres adresów IP , to sprawdza-

my zachowanie zapory zarówno dla adre-

sów granicznych, jak i leżących wewnątrz

i na zewnątrz zakresu. Warto przygoto-

wać sobie własne skrypty do testowania

zapory, dzięki czemu nie będziemy musieli

wciąż powtarzać wpisywania tych samych

komend. Również wprowadzanie popra-

wek jest w takim przypadku łatwiejsze.

lizatory integralności systemu) pewną

wielką wadę – dzięki niemu dowiadu-

jemy się o ataku, który już doszedł do

skutku. Cała sztuka polega na tym, aby

wykryć atak jeszcze w czasie jego prze-

prowadzania i odpowiednio go zablo-

kować.

Jednym z najlepszych programów

przeznaczonych do tego celu jest Snort .

Program nasłuchuje na wskazanych inter-

fejsach sieciowych, analizując pojawiające

się tam pakiety. Analizowane są one pod

kątem informacji istotnych dla bezpie-

czeństwa lub sprawnego funkcjonowania

sieci. Dzięki skonfigurowaniu odpowied-

nich preprocesorów, możemy polecić

Snortowi wyszukiwanie informacji o pró-

bach skanowania portów, atakach zwią-

zanych z błędną fragmentacją pakietów

IP , czy próby ukrycia ataków poprzez

zakodowanie adresów HTTP URI .

Następnie pakiety są przekazywane

do modułu, który porównuje je z regu-

łami opisującymi różne znane metody

ataków (tzw. sygnaturami ataków). Do

nas należy wybranie sygnatur, które

będą potrzebne w naszym systemie. Sam

Snort nie potrafi określić, czy w naszej

sieci połączenie na konkretny port jest

legalne, czy też powinien je traktować

jako próbę włamania – o tym my decy-

dujemy podczas konfiguracji. Jeśli zosta-

nie wykryty atak, Snort może zareago-

wać na wiele różnych sposobów. Oprócz

powiadomienia administratora i zapisa-

nia informacji o ataku, może również

podjąć środki zaradcze, np. przerywa-

jąc połączenie z komputerem potencjal-

nego włamywacza, a nawet odpowiednio

zmieniając zaporę sieciową.

Z takim zabezpieczaniem należy

uważać, gdyż może to doprowadzić do

tego, że intruz zdezorganizuje naszą

pracę symulując przeprowadzanie ataków

z sieci, na których nam zależy. Można to

oczywiście obejść odpowiednio modyfi-

kując nasze skrypty. Generalnie Snort nie

jest może zbyt łatwy w konfiguracji, ale

jeśli sobie z tym poradzimy, to uzyska-

my narzędzie porównywalne z produkta-

mi komercyjnymi. Dzięki niemu nie tylko

będziemy mogli wykrywać ataki, ale

również dowiadywać się o innych pro-

blemach w naszej sieci, np. związanych

z błędami w oprogramowaniu.

Testowanie zapory

Po zbudowaniu zapory sieciowej najważ-

niejsze jest jej dokładne przetestowanie.

Niestety, IPTables nie obsługuje opcje -C ,

znanej z IPChains , pozwalającej na łatwe

testowanie reguł. Musimy więc radzić

sobie łącząc się z zaporą z różnych maszyn

umieszczonych w Internecie i sieci lokal-

nej lub korzystając z innego oprogramo-

wania. Przykładowe programy, które mogą

okazać się bardzo pomocne przy testowa-

niu zapory, to HPing i Firewall Tester . O

programie HPing można było niedawno

przeczytać w Linux+ , więc zapoznajmy się

z drugim z programów.

Firewall Tester to zestaw skryptów

napisanych w Perlu , które można wyko-

rzystywać nie tylko do testowania jako-

ści zapory sieciowej, ale również syste-

mów wykrywania włamań. Do działania

Firewall Tester potrzebuje trzech modu-

Systemy wykrywania

włamań

Zapoznaliśmy się już z programem Afick ,

ale posiada on (podobnie jak inne ana-

Rysunek 5. Aick wydaje się być godnym

następcą sławnego Tripwire

Instalacja i obsługa Snorta

Program Snort możemy pobrać ze strony

domowejprojektu( http://www.snort.org/ ),

styczeń 2005

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: