plik

bezpieczeństwo

styczeń 2005

Bezpieczne

łączenie się

z Internetem

Piotr Machej

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

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ć

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-

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

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

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/