bezpieczeństwo

26

styczeń 2005

Bezpieczne

łączenie się

z Internetem

Piotr Machej

J

eśli ktoś jeszcze wierzy, że w dzisiej-
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.

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ć.

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

Na płycie CD/DVD

Na płycie CD/DVD znajduje się

oprogramowanie omawiane

w artykule.

Rysunek 1.

Na stronach serwisu SANS

możemy znaleźć obszerne wskazówki
dotyczące wykrywania intruzów

27

bezpieczeństwo

bezpieczny internet

www.lpmagazine.org

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.

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.

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.

Bez haseł w SSH

Jeśli mamy uruchomiony serwer SSH, do
którego powinni mieć dostęp tylko wybra-

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:

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-

Rysunek 2.

Część z tych nasłuchujących

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

28

bezpieczeństwo

styczeń 2005

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:

mkdir .ssh/
chmod 700 .ssh/

Teraz pozostaje nam dodać klucz publicz-
ny do spisu kluczy, które mogą być
wykorzystywane do łączenia się z tym
kontem:

cat id_rsa.pub >> .ssh/authorized_keys
chmod 600 authorized_keys

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:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

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

.

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

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, finger, 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.

Rysunek 3.

John the Ripper to tylko

jeden z wielu programów umożliwiających
testowanie siły haseł

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.

zapisanym w bazie. Oczywiście, jeśli sami
dokonamy zmian w plikach (na przykład
ze względu na aktualizację oprogramowa-

29

bezpieczeństwo

bezpieczny internet

www.lpmagazine.org

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.

Konfiguracja Aficka

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

ustawienia domyślne powinny wystarczyć,
lecz w razie potrzeby można je zmodyfi-
kować. Plik konfiguracyjny posiada dosyć
obszerne i czytelne komentarze.

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.

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,

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.

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

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.

Rysunek 4.

Konfigurację Aficka możemy

zmienić także z użyciem Webmina

30

bezpieczeństwo

styczeń 2005

(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.

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-

łó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.

Systemy wykrywania

włamań

Zapoznaliśmy się już z programem Afick,
ale posiada on (podobnie jak inne ana-

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.

Instalacja i obsługa Snorta

Program Snort możemy pobrać ze strony
domowej projektu (http://www.snort.org/ ),

Rysunek 5.

Afick wydaje się być godnym

następcą sławnego Tripwire

31

bezpieczeństwo

bezpieczny internet

www.lpmagazine.org

gdzie dostępne są nie tylko źródła, ale
i pakiety binarne (RPM). Można też sko-
rzystać z pakietów dostępnych w róż-
nych repozytoriach (np. DAG – http://
dag.wieers.com/packages/snort/ ). Przed
uruchomieniem warto sprawdzić, czy
Snort będzie oczekiwał na połączenia
na właściwym interfejsie. Informacja ta
umieszczona jest w pliku /etc/sysconfig/
snort w linii

INTERFACE="eth0"

. Jeśli do

łączenia z siecią wykorzystujemy inny
interfejs, należy poprawić tą wartość.
Warto też sprawdzić konfigurację zawar-
tą w pliku /etc/snort/snort.conf. Później
już możemy uruchomić Snorta polece-
niem

/etc/rc.d/init.d/snortd start

.

Jeśli teraz popatrzymy do pliku /var/
log/messages, od razu zobaczymy znacz-
ny przyrost liczby komunikatów. Oprócz
tego, pojawi się katalog /var/log/snort/.
Własnoręczna analiza tylu komunika-
tów nie ma sensu – lepiej skorzystać z
gotowych narzędzi. Dostępne są one na
stronie http://www.snort.org/dl/contrib/
wraz z innymi narzędziami przydatnymi
w zarządzaniu Snortem.

Zasady korzystania

z komputera

Jeśli naprawdę zależy nam na bezpiecz-
nym korzystaniu z sieci, nie powinniśmy
ograniczać się do jednorazowego zadba-
nia o bezpieczeństwo. Każdego dnia
pojawiają się komunikaty o wykryciu
kolejnych błędów w oprogramowaniu.
Część z tych błędów może mieć mniej-
sze lub większe znaczenie dla bezpie-
czeństwa. Jeśli nie zadbamy o uaktual-
nienia oprogramowania, cała nasza praca
może pójść na marne. Czasem przez
naszą pomyłkę, zaniedbanie lub nieświa-
domość możemy otworzyć włamywa-
czowi drogę do naszego systemu. Z tego
powodu podczas codziennego korzysta-
nia z komputera powinniśmy stosować
się do szeregu zaleceń:

• Z konta superużytkownika (root)

korzystamy tylko w bardzo wyjątko-
wych okolicznościach. Nawet w przy-
padku instalacji oprogramowania ze
źródeł, uprawnienia administratora
uzyskujemy tylko na czas potrzeb-
ny do uruchomienia polecenia

make

install

.

• Regularnie uaktualniamy system, inst-

alując poprawione wersje oprogra-
mowania (w tym również jądra).
Łączy się to ze śledzeniem serwi-
sów dotyczących bezpieczeństwa,
jak również stron domowych pro-
gramów zainstalowanych na naszym
dysku. Jeśli dla naszej dystrybu-
cji dostępne są serwery z aktuali-
zacjami, to powinniśmy z nich sko-
rzystać.

• Nigdy nie instalujemy oprogramo-

wania pochodzącego z nieznane-
go źródła. Mam tu na myśli przy-
godnych znajomych spotkanych na
IRC, czy serwery z oprogramowa-
niem, o którym niewiele lub nic nie
wiemy. Nie znaczy to, że pobierając
pliki z bardzo popularnych serwisów
jesteśmy całkiem bezpieczni – zda-
rzały się już przypadki podrzucenia
na takie serwery oprogramowania z
koniami trojańskimi.

• Przy instalowaniu programów powin-

niśmy w miarę możliwości sprawdzać
podpisy PGP oraz sumy MD5 pobra-
nych plików. Pozwoli to upewnić się,
że oprogramowanie otrzymaliśmy w
takiej postaci, w jakiej zamierzyli to
autorzy.

• Zawsze stosujemy hasła trudne do

złamania. Staramy się unikać prze-
syłania haseł kanałami niekodowa-
nymi (np. w przypadku korzystania
z poczty należy używać szyfrowania
SSL). Jeśli nie mamy możliwości prze-
syłania hasła w postaci zakodowanej,
to należy zadbać, aby było ono uni-
kalne (nie powinniśmy go wykorzy-
stywać nigdzie indziej). Dzięki temu
w razie jego przechwycenia przez
włamywacza, narażona będzie tylko
jedna usługa (np. zdalna poczta), a
nie cały system.

• Regularnie przeglądamy logi systemo-

we – samodzielnie lub z pomocą ana-
lizatorów logów, wysyłających powia-
domienia pocztą elektroniczną.

• Wykonujemy kopie zapasowe istot-

nych danych. Najlepiej wykonywać
je na płytach CD, lecz w razie braku

nagrywarki powinniśmy kopie umie-
ścić na innej partycji, dysku lub kom-
puterze.

• Nie

udostępniamy

komputera

osobom, których nie znamy lub do
których nie mamy zaufania. Dotyczy
to nie tylko umożliwiania dostępu
przez SSH czy FTP, ale także dostępu
fizycznego. Nie wykonujemy też żad-
nych poleceń podanych nam przez
takie osoby, jeśli nie jesteśmy absolut-
nie pewni, co dane polecenie robi.

Zakończenie

Większość prób włamań do naszych
komputerów jest wynikiem działania tzw.
script kiddies, czyli osób – z reguły dość
młodych – używających gotowych roz-
wiązań. Korzystają oni zazwyczaj z tych
samych źródeł informacji co my, zatem
będąc na bieżąco mamy całkiem sporą
szansę, że nie uda im się spenetrować
naszego systemu. Dbajmy o nasz system,
a wówczas będziemy mogli z czystym
sumieniem wędrować po naszej global-
nej sieci.

Rysunek 6.

Snort jest wciąż rozwijany,

a na jego stronie można znaleźć obszerną
dokumentację

W Internecie:

• Afick:

http://afick.sourceforge.net/

• Firewall Builder:

http://www.fwbuilder.org/

• HPing:

http://wiki.hping.org/

• Firewall Tester:

http://ftester.sourceforge.net/

• Snort:

http://www.snort.org/

• Lista dwudziestu najpoważniejszych

zagrożeń dla bezpieczeństwa:
http://www.sans.org/top20/

• SANS:

http://www.sans.org/

• Secunia:

http://secunia.com/

• SecurityFocus:

http://www.securityfocus.com/

• CERT Coordination Center:

http://www.cert.org/

• LinuxToday:

http://linuxtoday.com/

• Artykuł o uwierzytelnianiu z wykorzy-

staniem kluczy w OpenSSH:
http://www.securityfocus.com/
infocus/1810/

• Serwis IPSec.pl:

http://ipsec.pl/

• Serwis Hacking.pl:

http://hacking.pl/