Akademia Górniczo  Hutnicza
im. Stanisława Staszica w Krakowie
Wydział Elektrotechniki, Automatyki,
Informatyki i Elektroniki
Katedra Informatyki
Praca dyplomowa  inżynierska
Wybrane zagadnienia bezpieczeństwa
systemu Linux
Autor:
Izabela Kopij
Promotor:
dr inż. Jarosław Koz
lak
Kierunek:
Informatyka
Kraków, 2004
Spis treści
Spis rysunków 5
Spis listingów 7
1 Wstęp 8
1.1 Potrzeba zabezpieczeń . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Instalacja systemu 11
2.1 Partycjonowanie dysku . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Root  / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 /usr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4 /boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.5 /home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.6 /tmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.7 /var . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.8 Uwagi końcowe . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Wybór systemu plików . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Hasła md5 i shadow passwords . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Security Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Inne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1 Lepki bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.2 SUID i SGID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.3 Właściwy sposób podłączania partycji . . . . . . . . . . . . . . . 18
3 Fizyczny dostęp do komputera 21
3.1 Dostęp bezpośredni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
SPIS TREŚCI 2
3.1.1 BIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.2 LILO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Bezpieczna zdalna administracja systemem 28
4.1 Telnet a SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Powłoka SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Zasada działania powłoki SSH . . . . . . . . . . . . . . . . . . . 30
4.2.2 Programy powłoki SSH . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Dodatkowe opcje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Zdalne uruchamianie sesji X Window . . . . . . . . . . . . . . . 32
4.3.2 Brak możliwości logowania jako root . . . . . . . . . . . . . . . 33
4.3.3 Logowanie za pomocą klucza . . . . . . . . . . . . . . . . . . . 33
4.4 Uwagi końcowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5 Hasła w systemie 36
5.1 Bezpieczna postać haseł . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1 Wymuszanie stosowania bezpiecznych haseł . . . . . . . . . . . 37
5.1.2 Hasła jednorazowe . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Moduł PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Zasada działania . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.2 Weryfikacja haseł podczas ich wybierania . . . . . . . . . . . . . 40
5.3 Wymuszanie regularnych zmian hasła . . . . . . . . . . . . . . . . . . . 41
5.4 Inżynieria społeczna  jak nie używając komputera zdobyć hasło? . . . . 41
5.5 A
amanie haseł . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.1 Crack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5.2 John the Ripper . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.6 Środki zaradcze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6 Ataki 45
6.1 Omiatanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1.1 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1.2 Zapobieganie omiataniu . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Usługi systemu operacyjnego podatne na atak . . . . . . . . . . . . . . . 47
6.2.1 Skanowanie portów  identyfikacja usług . . . . . . . . . . . . . 47
6.2.2 Ataki typu  odmowa usługi . . . . . . . . . . . . . . . . . . . . 52
6.2.3 Ataki typu  przepełnienie bufora . . . . . . . . . . . . . . . . . 52
SPIS TREŚCI 3
6.3 Zakłócenia pracy sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3.1 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3.2 Trasowanie z użyciem fałszywego z
ródła pakietu . . . . . . . . . 54
6.4 Podszywanie się . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.4.1 Non-blind spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4.2 Blind spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4.3 Man In the Middle Attack . . . . . . . . . . . . . . . . . . . . . 56
6.4.4 Fałszowanie adresu MAC . . . . . . . . . . . . . . . . . . . . . 56
7 Środowisko graficzne 57
7.1 Bezpieczeństwo WDM . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2 Serwery X11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2.1 Wyłączenie dostępu z sieci na poziomie WDM . . . . . . . . . . 60
7.2.2 Wyłączenie dostępu z sieci na poziomie jądra . . . . . . . . . . . 61
7.2.3 Blokowanie na poziomie Xhost . . . . . . . . . . . . . . . . . . 61
7.3 Serwer X i SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.4 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8 Poczta elektroniczna 65
8.1 Wybór programów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.2 Konfiguracja Postfix a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.2.1 Ograniczenie zasobów . . . . . . . . . . . . . . . . . . . . . . . 68
8.2.2 Ograniczenia listów przychodzących i wychodzących . . . . . . . 68
8.2.3 Postfix + SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.3 MKSvir i Amavis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9 Zapora ogniowa 76
9.1 Firewalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.1.1 Filtrowanie pakietów . . . . . . . . . . . . . . . . . . . . . . . . 77
9.1.2 Systemy pośredniczące . . . . . . . . . . . . . . . . . . . . . . . 78
9.1.3 Hosty bastionowe . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.1.4 Firewalle aplikacyjne . . . . . . . . . . . . . . . . . . . . . . . . 79
9.2 Iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.2.1 Stany pakietów . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.2.2 A
ańcuchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.2.3 Dopasowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
SPIS TREŚCI 4
9.2.4 Cele i skoki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.3 Przykładowy Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.3.1 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10 Wykrywanie intruzów 90
10.1 Sprawdzanie integralności . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.2 Poszukiwanie i wykrywanie anomalii . . . . . . . . . . . . . . . . . . . 91
10.3 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.3.1 Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.3.2 Packet logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
10.3.3 Network intrusion detection . . . . . . . . . . . . . . . . . . . . 94
10.4 Konfiguracja Snorta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
10.4.1 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
11 Zakończenie 96
Bibliografia 98
Spis rysunków
2.1 Zaawansowany podział dysku na partycje . . . . . . . . . . . . . . . . . 12
2.2 Wybór hasła md5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Zgoda na pobieranie poprawionych uaktualnień . . . . . . . . . . . . . . 16
3.1 Kolejność uruchamiania systemu z urządzeń . . . . . . . . . . . . . . . . 22
3.2 Wykorzystanie niezabezpieczonego LILO . . . . . . . . . . . . . . . . . 24
4.1 Próba skanowania transmisji SSH . . . . . . . . . . . . . . . . . . . . . 29
Spis listingów
2.1 Sposób na ominięcie opcji NOEXEC . . . . . . . . . . . . . . . . . . . . 18
2.2 Konfiguracja pliku apt.conf . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Konfiguracja pliku fstab . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Domyślna konfiguracja LILO . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Lokalne ustawienie haseł w LILO . . . . . . . . . . . . . . . . . . . . . 25
3.3 Możliwość uruchomienia systemu z dyskietki i CD . . . . . . . . . . . . 25
3.4 Zabezpieczenie czytnika dyskietek i CDROM w LILO . . . . . . . . . . 26
4.1 Zdobywanie hasła za pomocą Telnetu . . . . . . . . . . . . . . . . . . . 28
5.1 Domyślna konfiguracja PAM dla usługi su . . . . . . . . . . . . . . . . . 38
5.2 Przykład konfiguracji modułu pam_ cracklib.so . . . . . . . . . . . . . . 40
5.3 Przykładowa zawartość pliku /var/log/auth.log . . . . . . . . . . . . . . . 42
5.4 Rezultat działania programu John the Ripper . . . . . . . . . . . . . . . . 44
6.1 Efekt omiatania programem Nmap . . . . . . . . . . . . . . . . . . . . . 46
6.2 Ograniczanie częstotliwości omiatania . . . . . . . . . . . . . . . . . . . 46
6.3 Skanowanie portów za pomocą programu Nmap . . . . . . . . . . . . . . 47
6.4 Netstat  pobieranie informacji o tym, które porty w systemie są otwarte . 48
6.5 Sprawdzanie informacji o pakiecie . . . . . . . . . . . . . . . . . . . . . 50
6.6 Usuwanie usługi przez usunięcie pakietu . . . . . . . . . . . . . . . . . . 50
6.7 Blokowanie usług w /etc/inetd.conf . . . . . . . . . . . . . . . . . . . . . 51
7.1 Reguły iptables kontrolujące dostęp do WDM . . . . . . . . . . . . . . . 59
7.2 Skrypt blokujący nasłuchiwanie serwera X . . . . . . . . . . . . . . . . . 60
7.3 Uruchamianie globalnego blokowania nasłuchiwania serwera X . . . . . 60
7.4 Zmiany w pliku Xservers . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.5 Reguły iptables selektywnie blokujące połączenia . . . . . . . . . . . . . 61
7.6 Procedura dodawania zaufanego hosta do xhost . . . . . . . . . . . . . . 61
7.7 Akceptowane przez przykładowy system  cookies . . . . . . . . . . . . 62
7.8 Nowe  cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
SPIS LISTINGÓW 7
7.9 Interaktywna sesja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1 Standardowa zawartość pliku /etc/postfix/main.cf . . . . . . . . . . . . . 67
8.2 Konfiguracja SASL dla Postfix a . . . . . . . . . . . . . . . . . . . . . . 71
8.3 Dodatkowa konfiguracja main.cf . . . . . . . . . . . . . . . . . . . . . . 71
8.4 Pobieranie antywirusa MKSvir . . . . . . . . . . . . . . . . . . . . . . . 72
8.5 Instalacja antywirusa MKSvir . . . . . . . . . . . . . . . . . . . . . . . . 73
8.6 Wynik testowego skanowania antywirusem . . . . . . . . . . . . . . . . 73
8.7 Instalacja i uruchomienie demona przyspieszającego proces skanowania . 74
8.8 Test demona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.9 Instalacja programu Amavis . . . . . . . . . . . . . . . . . . . . . . . . . 75
Rozdział 1
Wstęp
1.1 Potrzeba zabezpieczeń
Od kiedy rozpoczęła się epoka komputerów, a wraz z nią gwałtowna ekspansja Inter-
netu, zdobywanie określonych informacji stało się nieprzeciętnie łatwe. Informacja jest
wszędzie, żeby ją zdobyć potrzeba tylko odrobinę wysiłku i dobrej woli.
To jedno oblicze problemu  informacja jest wszędzie  wyciągnij dłoń, a będziesz ją
mieć. Druga strona medalu już nie jest taka  różowa . Skoro można tak łatwo zdobyć
informacje, to w jaki sposób zabezpieczyć się przed niekontrolowanym dostępem? Co
zrobić aby, poufne informacje nie znalazły się w niepowołanych rękach?
Gdyby świat był doskonały, nie byłoby zła, nieuczciwości i kłamstwa. Niestety jest
jak jest i nie da się tego zmienić  zawsze będą istnieć osoby, które w jakiś sposób będą
chciały dostać się do naszego systemu w celu zdobycia określonych danych, zmienienia
ich, albo co gorsza zniszczenia. Zasady netykiety, określone w 1992 r. przez Arlene
Rinaldi, szerzej znane jako dokument RFC 1855, niestety nie są w stanie zmienić nasta-
wienia człowieka, by jego działanie nie budziło ani etycznych ani moralnych wątpliwości.
Co więcej, nawet specyficzne zasady  różnorodne etyki  grup hakerskich także nie na-
kazują ani nie zmuszają do określonego postępowania. Dowiemy się z nich tylko, że
 prawdziwy haker poznaje system w celu samokształcenia, wykrywania w nim luk, itd.
 Prawdziwy haker nie niszczy danych, nie zdobywa ich, by użyć w  niecnych celach.
Ale na ile młody licealista, który ma nadmiar wolnego czasu, niedomiar środków pie-
niężnych będzie się z taką ideologią utożsamiał, szczególnie, gdy niektóre dane są warte
więcej niż jest on w stanie sobie to wyobrazić? Dywagować na ten temat można by długo,
nie jest to jednak moim celem. Chcę zwrócić tylko uwagę na fakt, że kiedy sieć Inter-
net nie była popularna, systemy były głównie jednostanowiskowe, a nawet gdy już była
1.1. Potrzeba zabezpieczeń 9
możliwa praca w sieci (w roku 1980 opracowano protokoły TCP/IP dla systemu UNIX,
by w 1983 TCP/IP zostało włączone do ogólnie dostępnej wersji UNIXa) bezpieczeństwo
systemów opierało się wzajemnym zaufaniu użytkowników.
Dopiero wraz z gwałtownym wzrostem popularności sieci, coraz większą ilością użyt-
kowników, zabezpieczanie przed niekontrolowanym dostępem stało się koniecznością.
Powoli zaczęły pojawiać się pierwsze mechanizmy zabezpieczeń, ale równolegle z nimi
powstawały sposoby ich łamania.
Na początku zabezpieczanie polegało na stosowaniu haseł, do których kodowania wy-
korzystywano wpierw algorytm DES póz
niej MD5. Jednak wraz z powstaniem różnych
metod łamania coraz mocniejszych haseł, programy łamiące hasła też stawały się coraz
bardziej zaawansowane. Przykładem mogą być dwa programy Crack i John the Ripper,
które najczęściej wykorzystuje się do łamania haseł. Pierwszy korzysta ze stosunkowo
prostych reguł opartych na słowniku i jest w stanie złamać hasła, które zostały zakodo-
wane przy użyciu algorytmu DES. Drugi program, znacznie nowszy, potrafi łamać hasła
zakodowane mocniejszym algorytmem MD5.
Znacznie póz
niej pojawiły się specjalne moduły pomagające dobrze zabezpieczyć
system (np. moduł PAM), by w końcu powstały całe systemy, których zadaniem jest
wykrywanie intruzów, bieżące monitorowanie systemu oraz sieci w której pracuje (np.
system Snort).
Dodatkowe moduły zabezpieczające oraz systemy monitorujące ruch były odpowie-
dzią na coraz powszechniejsze ataki typu odmowa usługi, przepełnienie bufora, fałszowa-
nie z
ródła pakietu, fałszowanie adresu MAC oraz pochodne tych ataków.
Kiedy pojawiło się środowisko graficzne, równocześnie pojawił się problem bezpiecz-
nego dostępu do tak zdalnego jak i lokalnego. Znaleziono na to połowiczne rozwiązanie
 z jednej strony blokowanie dostępu z sieci do menadżera okien, z drugiej łączenie się z
menadżerem poprzez zaszyfrowaną sesję wykorzystującą SSH.
Poczta elektroniczna, która do czasów obecnych jest najpopularniejszym sposobem
wykorzystania Internetu też nie uchowała się przed atakami takimi jak bomby mailowe,
czy DoS. Szybko jednak powstały serwery poczty, np. Postfix, tak mocno konfigurowalne,
że one same, bez dodatkowych aplikacji potrafią zapobiegać takim atakom. Natomiast
dodatkowe aplikacje, takie jak MKSvir czy Amavis, których działanie można połączyć z
pracą serwera poczty, dodatkowo pomagają w zwalczaniu wirusów i spamu.
Jak widać rywalizacja między tworzeniem nowych zabezpieczeń i powstawaniem co-
raz nowszych metod ich łamania trwa do dnia dzisiejszego i prawdopodobnie nigdy się
nie skończy.
1.2. Cel pracy 10
Stąd zabezpieczanie się przed niekontrolowanymi działaniami osób postronnych nie
jest już fanaberią jakiegoś ekscentryka, tylko podstawową koniecznością obecnych cza-
sów.
1.2 Cel pracy
Celem pracy jest opisanie sposobów zabezpieczania systemu Debian Linux w wersji
Stable  Woody, pod kątem różnego rodzaju ataków. Wykorzystując maszynę wirtualną
VMWare, zostanie zainstalowany system pracujący na jądrze 2.4.18-bf2.4. Wybór padł na
jądro serii 2.4.* dlatego, że wykorzystuje ono, do filtrowania pakietów, Iptables. Podany,
przykładowy firewall będzie wykorzystywał właśnie Iptables.
Domyślnym środowiskiem graficznym będzie Window Maker, ponieważ jest szybki
oraz nie wymaga dużo przestrzeni na dysku.
Serwer poczty, którego instalacja i konfiguracja będzie opisana, to bardzo wydajny
program  Postfix, który po połączeniu z aplikacjami MKSvir i Amavis będzie dodatkowo
zapobiegał rozprzestrzenianiu się wirusów i rozsyłaniu spamu.
W pracy będzie pokazane, jak ważny jest, pozornie mało istotny pod kątem bezpie-
czeństwa, proces instalacji systemu oraz bezpośredni, fizyczny dostęp do komputera i
systemu.
Dużym problemem w praktyce każdego administratora systemu są hasła i użytkow-
nicy, którzy je używają. Stąd w pracy zostanie omówiona idea poprawnych haseł, będą
pokazane przykłady tworzenia poprawnych haseł oraz sposoby ich zapamiętania.
Metody wykrywania intruzów, sprawdzanie integralności systemu, poszukiwanie i
wykrywanie anomalii w systemie, to ważne aspekty bezpieczeństwa. W pracy te pro-
blemy będą omówione na konkretnym przykładzie systemu Snort.
Rozdział 2
Instalacja systemu
Przeprowadzana instalacja systemu, zgodnie z początkowymi założeniami, ma dać
w efekcie podstawowy system, ze standardowymi konfiguracjami. To zaś ma na celu
pokazanie, w których miejscach systemu można znalez
ć  dziury pozwalające na nie-
kontrolowany dostęp do maszyny.
Niemniej, w trakcie instalacji jest kilka momentów, w których należy wybrać bardziej
bezpieczne opcje  ten rozdział także mówi o nich.
2.1 Partycjonowanie dysku
Pierwszą ważną czynnością, którą należy wykonać, by nie popsuć od razu bezpie-
czeństwa systemu, to odpowiednie ustawienie partycji.
Na początek trzeba zadać pytanie:  Jakie zadania system ma spełniać? ,  Jakie ma
pełnić role? . I w zależności od tego, czy system ma być stacją roboczą, serwerem poczty,
serwerem WWW, serwerem nazw, ma udostępniać konta shell użytkownikom oraz ma
być serwerem FTP, czy ma pełnić inne role  w taki sposób ustawiamy partycje.
Testowy komputer ma dysk o pojemności 4 GB i 160 MB pamięci RAM, zatem
najrozsądniejszym rozwiązaniem będzie, gdy dysk podzielimy na 7 partycji1: swap 
180MB, /  ok. 750MB, /home  ok. 750MB, /usr  1200MB, /tmp  500MB, /var 
800MB, /boot  16MB.
2.1.1 Swap
Swap powinien mieć wielkość w przybliżeniu równą wielkości posiadanej pamięci
1
http://www.debian.org/doc/packaging-manuals/fhs/
2.1. Partycjonowanie dysku 12
Rysunek 2.1: Zaawansowany podział dysku na partycje
RAM. Ta partycja jest wymagana przez system i jest wirtualną pamięcią dla systemu,
który wykorzystuje ją, gdy zaczyna brakować mu pamięci RAM.
2.1.2 Root  /
/  główna partycja systemu. Tutaj znajdują się pliki konfiguracyjne, pliki systemowe,
a także wszelkie informacje o tym jak system ma wystartować, w jaki sposób odtwo-
rzyć uszkodzony system. Do tej partycji montowane są wszystkie pozostałe partycje oraz
mieszczą się na niej te dane, które nie są umieszczone na oddzielnych partycjach. Należy
pamiętać, że ta partycja powinna być mała. Uszkodzenie tej partycji  katalogu stanowi
dużo większy problem dla systemu niż uszkodzenie każdej innej partycji, stąd właśnie
postulat, by partycja nie była zbyt duża  by łatwo można było robić jej kopie zapasowe.
2.1.3 /usr
/usr  drugi po / najważniejszy katalog systemowy. Tutaj znajduje się większość za-
instalowanych w systemie programów. Ten katalog systemowy, powinien być na osobnej
partycji, tak jak w naszym przypadku, z tego względu, że może być w ten sposób za-
montowany w trybie read-only  tylko do odczytu. Dzięki temu zwykły użytkownik nie
będzie mógł wprowadzać tutaj żadnych zmian.
Odpowiednie ustawienie praw dostępu może zapobiec niekontrolowanemu wprowa-
dzaniu zmian w programach przez użytkowników. Jest to katalog  zbiorczy , w którym
2.1. Partycjonowanie dysku 13
znajdują się podkatalogi: X11R6  system X Window, bin  większość najbardziej uży-
tecznych komend, games  gry i naukowe binaria, include  nagłówki plików używanych
przez programy pisane w języku C, lib  biblioteki, local  lokalna hierarchia, katalog
zwykle pusty po głównej instalacji, sbin  współdzielone pliki binarne systemu, share 
niezależne pliki programów, src  kod z
ródłowy.
2.1.4 /boot
/boot  na tej partycji znajduje się wszystko to, co jest potrzebne do uruchomienia
systemu, poza plikami konfiguracyjnymi. Tutaj znajdują się fragmenty kodu jądra, które
są uruchamiane zanim jądro przejdzie w tryb użytkownika. Tutaj mogą się znajdować
zachowane główne sektory dysku, mapa sektorów oraz wszelkie pliki, które zwykle nie
są poddawane edycji ręcznej.
2.1.5 /home
/home  katalog przeznaczony na konta użytkowników. Osobna partycja dla tego
katalogu zdecydowanie wydaje się najwłaściwszym rozwiązaniem.
W małych systemach można sobie pozwolić na to, by każde konto użytkownika było
bezpośrednio w katalogu /home, w dużych, ze względu na przejrzystość systemu, dobrze
jest stworzyć określone grupy użytkowników, a w nich osobne konta. Osobne grupy użyt-
kowników mają tę zaletę, że dużo prościej można określić uprawnienia poszczególnych
użytkowników.
2.1.6 /tmp
/tmp  katalog przeznaczony na pliki tymczasowe dla programów, które mogą tego
wymagać. Pliki znajdujące się w tym katalogu, zwykle są usuwane po każdym ponownym
uruchomieniu systemu.
2.1.7 /var
W tym katalogu znajdują się zmienne pliki danych, takie jak np. pliki dzienników
(tzw. logi), pliki przejściowe i czasowe. Ten katalog jest dzielony przez wiele aplika-
cji np. poczta przechowuje tutaj wiadomości, mogą się także w tym miejscu znajdować
strony WWW. Jak żaden inny, ten katalog powinien być usytuowany na osobnej partycji,
2.2. Wybór systemu plików 14
ponieważ ten katalog ma tendencję do systematycznego rozrastania się. Może to prowa-
dzić do przepełnienia dysku.
2.1.8 Uwagi końcowe
Jak widać mój podział dysku na partycje odpowiadające katalogom systemowym jest
jak najbardziej uzasadniony i to z dwóch powodów. Po pierwsze bezpieczeństwo  osobne
partycje dla katalogów systemowych minimalizują ryzyko uszkodzenia systemu, pozwa-
lają na swobodniejsze tworzenie kopii zapasowych. Drugi powód to znaczne ułatwienie
w zarządzaniu systemem, dzięki czemu można już na starcie określić miejsca w których
użytkownicy będą mogli wprowadzać zmiany, do jakich zasobów będą mieli dostęp pełny,
a do których ograniczony.
2.2 Wybór systemu plików
W trakcie instalacji, gdy instalacja systemu zostanie uruchomiona z poleceniem:
boot: bf24
zaraz po partycjonowaniu dysku, system pyta o rodzaj systemu plików jaki będzie insta-
lowany dla poszczególnych partycji. W Debian Woody mamy do dyspozycji ext2 i ext3.
Należy wybrać ext3. Powód jest prosty  posiada wszystko to, co ma w sobie ext2, ale
dodatkowo wyposażony jest w plik dziennika. Wykorzystuje funkcje podsystemu JBD2,
przez co ext3 może wykorzystywać rejestrowanie transakcyjne.
Samo JBD umożliwia zadeklarowanie, czy mają być rejestrowane wszystkie zmiany
danych i metadanych3, czy też rejestrowanie ma obejmować wyłącznie zmiany meta-
danych systemu plików; gwarantuje także niepodzielność operacji zapisu zmian doty-
czących określonej aktualizacji systemu plików. Niepodzielność jest realizowana przez
znakowanie wszystkich wpisów dziennika identyfikatorem transakcji, z którą te wpisy są
związane oraz zastosowaniem specjalnych typów wpisów dla transakcji zakończonych.
Podsystem JBD korzysta z tzw. opóz
nionego zapisu, który buforuje wszystkie transakcje,
ale jednocześnie zapewnia, że w dzienniku zostaną zapisane tylko transakcje, które zo-
stały wykonane, albo żadna z nich. Z praktycznego punktu widzenia, dużo trudniej utracić
dane z systemu plików ext3 niż z ext2, co zdecydowanie wydaje się bezpieczniejszą opcją
niż ext2.
2
JBD  Journaling Block Device  urządzenie blokowe z kroniką
3
metadane  informacje o systemie plików, tzw. dane opisujące dane
2.3. Hasła md5 i shadow passwords 15
2.3 Hasła md5 i shadow passwords
Kolejny punkt instalacji, na który powinno się zwrócić uwagę, ustawienie domyślnego
szyfrowania haseł wykorzystującego algorytm MD5. Rysunek 2.2 pokazuje odpowiedni
zrzut ekranu z instalacji.
Dlaczego hasła powinny być szyfrowane takim algorytmem? Są one po prostu bez-
pieczniejsze ze względu na to, że długość haseł nie jest ograniczona, tak jak w innych
algorytmach szyfrowania (np. w popularnym DES), przez co mają znacznie większy ob-
szar klucza (można stosować w hasłach m.in. znaki interpunkcyjne).
Rysunek 2.2: Wybór hasła md5
Należy tutaj wspomnieć w jaki sposób są szyfrowane hasła w Linuksie. Po pierw-
sze są przechowywane w systemie w postaci zaszyfrowanej. Wymaga ono konwersji
łańcucha znaków za pomocą powtarzalnego algorytmu (w naszym przypadku MD5), do
postaci, która będzie znacznie się różnić od łańcucha wyjściowego. Algorytm musi być
powtarzalny, ponieważ wykorzystywany jest za każdym razem, gdy użytkownik loguje
się do systemu, tworzony jest identyczny łańcuch znaków z tym, który w systemie jest
już przechowywany.
W Linuksie wykorzystywana jest tzw. jednokierunkowa funkcja skrótu, dzięki któ-
rej hasło można zaszyfrować, nie można natomiast odszyfrować hasła z zaszyfrowanej
wartości.
Kolejną opcją, którą zaznaczamy, to  yes przy wyborze shadow passwords. Dzięki
temu hasła tworzone w systemie nie będą przechowywane w pliku /etc/passwd, ale w
2.4. Security Updates 16
pliku /etc/shadow. Różnica między tymi plikami polega na tym, że /etc/passwd może od-
czytać każdy użytkownik, natomiast /etc/shadow jest do odczytu tylko dla administratora
i członków grupy  shadow .
Możliwość odczytu zwykłego pliku z hasłami, jakim jest /etc/passwd musi być moż-
liwa, by każde polecenie, usługa, które odwzorowuje nazwy użytkowników na identyfi-
katory UID mogły poprawnie działać. Nie ma natomiast takiego wymogu jeśli chodzi o
plik /etc/shadow.
2.4 Security Updates
Kolejny ważny krok podczas instalacji systemu, to umożliwienie systemowi pobiera-
nia  bezpiecznych uaktualnień pakietów, tzw. security updates. Na Rysunku 2.3 widać,
że instalator podpowiada, że system Debian posiada system uaktualnień dotyczących bez-
pieczeństwa i, że dobrym rozwiązaniem jest zgoda na pobieranie takich pakietów.
Rysunek 2.3: Zgoda na pobieranie poprawionych uaktualnień
W systemie Debian, jeśli zostanie wykryty jakiś błąd dotyczący bezpieczeństwa sys-
temu, w ciągu kilku godzin, maksymalnie do kilku dni, pojawia się w Internecie4 po-
prawiona wersja pakietu. Zgoda na domyślne pobieranie uaktualnionych i poprawionych
pod kątem bezpieczeństwa pakietów spowoduje, że system będzie, od strony samych pa-
kietów, możliwie maksymalnie bezpieczny.
4
Pod adresem: http://security.debian.org
2.5. Inne 17
Jeśli w trakcie instalacji nie zostanie zaznaczone, by uaktualnienia domyślnie się wy-
konywały, można to wykonać póz
niej, dodając do pliku /etc/apt/sources.list linię:
deb http://security.debian.org/ stable/updates main
Wtedy przy każdej aktualizacji systemu za pomocą:
mab:~# apt-get update && apt-get upgrade
będą one brane pod uwagę.
2.5 Inne
Linux jest systemem wielodostępowym  może z niego korzystać jednocześnie więcej
niż jeden użytkownik. Administrator (root), posiada wszelkie możliwe uprawnienia, stąd
zdobycie tych praw jest celem potencjalnego włamywacza. Istotne jest, by korzystając
z systemu nie pracować jako superużytkownik, nie tylko z tego powodu, że w takim
przypadku system jest bardziej podatny na atak, ale także dlatego, że zwykły użytkownik,
ze ściśle określonymi prawami może spowodować dużo mniej szkód niż root.
2.5.1 Lepki bit
Lepki bit to takie ustawienie uprawnień do katalogu, że użytkownik może usuwać z
katalogu tylko te pliki, które są jego własnością. W Linuksie lepki bit ustawia się za
pomocą opcji+t, np.:
mab:~# chmod +t /home
Idealnym zastosowaniem lepkiego bitu jest katalog /tmp. Wszyscy użytkownicy mogą
korzystać z tego katalogu i zapisywać tam pliki, natomiast usuwać mogą tylko swoje.
2.5.2 SUID i SGID
SUID I SGID to dodatkowe bity uprawnień, które można stosować poza standardo-
wymi (x, r, w) i lepkim bitem. Ich zadaniem jest spowodowanie uruchamiania programu
w kontekście konta użytkownika (zgodnie z własnościami grupy)  bez względu na to kto
(jaka grupa) ten program uruchomi. Ustawiamy to następująco:
2.5. Inne 18
#dla SUID
mab:~# chmod u+s suid_plik
#dla SGID
mab:~# chmod g+s sgid_plik
2.5.3 Właściwy sposób podłączania partycji
Podczas włączania do systemu partycji można przy okazji dodać kilka interesujących
opcji, które będą zwiększały bezpieczeństwo systemu.
NOEXEC
Opcja ta zabrania bezpośredniego uruchamiania programów. Tę opcję można stoso-
wać przy montowaniu partycji /tmp. Takie zabezpieczenie partycji nie jest zbyt mocne,
ponieważ można to ominąć, tak jak pokazane jest na Listingu 2.1
1 mab : ~ # mount / tmp / - o remount , n oe xec
2 mab : ~ # cp / b i n / l s / tmp
3 mab : ~ # / tmp / l s
4 bash : / tmp / l s : P e r m i s s i o n d e n i e d
5 mab : / tmp# / l i b / ld -l i n u x . so . 2 . / l s
6 l o s t + found l s
7 mab : / tmp#
Listing 2.1: Sposób na ominięcie opcji NOEXEC
Na początku montujemy partycję /tmp jako NOEXEC, co spowoduje, ze nie będzie można
bezpośrednio uruchomić żadnego programu z tej partycji. W kolejnym kroku kopiujemy
do /tmp przykładowy program ls. Linia trzecia to próba uruchomienia tego programu,
która kończy się brakiek dostępu (linia 4). Jednak spróbujmy wejść do katalogu /tmp i
wykorzystując bibliotekę /lib/ld-linux.so.2 uruchomić program ls w bieżącym katalogu.
Okazuje się, że w całkiem prosty sposób można uruchomić program.
NOSUID
Nie pozwala na działanie bitów set-user-id i set-group-id. Tę opcję najlepiej stosować
na partycje: /home, /tmp. O tych bitach powinien decydować tylko administrator i dlatego
nie powinno się ich ustawiać na partycjach, na których użytkownicy mają prawa zapisu.
2.5. Inne 19
NODEV
Nie interpretuje specjalnych urządzeń blokowych ani znakowych na systemie plików.
Można stosować do wszystkich partycji poza partycją główną /.
READ-ONLY
Tę opcję powinno się stosować dla partycji /usr. W ten sposób nie będzie możliwe
instalowanie nowego oprogramowania w systemie. Aby móc instalować nowe pakiety w
systemie konieczne będzie przesunięcie tej partycji w tryb read-write. W Debianie do in-
stalacji pakietów służy m.in. program Apt, który może być tak skonfigurowany, że będzie
uruchamiał określone polecenie przed i po aktualizacji. Można to zrobić modyfikując plik
/etc/apt/apt.conf tak jak na Listingu 2.2.
1 DPkg
2 {
3 Pre-I nvoke {   mount / u s r -o remount , rw   } ;
4 Post -Invok e {   mount / u s r -o remount , ro   } ;
5 } ;
Listing 2.2: Konfiguracja pliku apt.conf
Ostatecznie plik odpowiedzialny za automatyczne montowanie partycji  /etc/fstab będzie
mieć postać taką jak na Listingu 2.3.
1 / dev / sda3 / e x t 3 e r r o r s =remount-
r o 0 1
2 / dev / sda1 none swap sw
0 0
3 p r o c / p r o c p r o c d e f a u l t s
0 0
4 / dev / fd0 / f l o p p y a u t o u s e r , noauto ,
nodev , nosuid , noexec 0 0
5 / dev / cdrom / cdrom i s o 9 6 6 0 ro , u s e r , noauto ,
nodev , nosuid , noexec 0 0
6 / dev / sda5 / home e x t 3 rw , nosuid , nodev
, exec , a u t o 0 2
7 / dev / sda6 / u s r e x t 3 d e f a u l t s , ro ,
nodev 0 2
2.5. Inne 20
8 / dev / sda7 / tmp e x t 3 d e f a u l t s , nodev ,
nosuid , noexec 0 2
9 / dev / sda8 / v a r e x t 3 d e f a u l t s , nodev ,
nosuid , noexec 0 2
10 / dev / sda2 / b o o t e x t 3 d e f a u l t s , r o
0 2
Listing 2.3: Konfiguracja pliku fstab
Rozdział 3
Fizyczny dostęp do komputera
3.1 Dostęp bezpośredni
Mówi się, że ten, kto ma bezpośredni dostęp do komputera, ma już nad nim władzę
 może wszystko z nim zrobić, stąd poprzez bezpośredni dostęp fizyczny do komputera
rozumiem możliwość fizycznego kontaktu z komputerem.
Najprostszy sposób na zdobycie danych zawartych w takim komputerze to wyciągnię-
cie z niego dysku twardego. Dlatego ważne jest, by do pomieszczeń, w których znajdują
się ważne dane zapisane w różnego rodzaju pamięciach, miały dostęp tylko i wyłącznie
osoby uprawnione. Samo pomieszczenie z serwerami (tzw. serwerownia) powinno być
dostępne tylko dla wybranych osób, które bezpośrednio odpowiadają za stan danych i
serwerów. Dobrym rozwiązaniem jest, by serwery usług nie były jednocześnie stacjami
roboczymi. Jeśli nie jest to możliwe do zrealizowania (np. w małych firmach, kafejkach
internetowych, tzw. sieciach blokowych) i dany komputer służy jednocześnie za stację
roboczą o dostępie bezpośrednim oraz za serwer usług, dobrze jest ograniczyć ilość osób,
które mogą mieć kontakt bezpośredni z danym komputerem.
Jeśli chodzi o komputery w innych pomieszczeniach, do których bez większego trudu
mogą dostać się różne osoby, także w jakiś sposób powinny być monitorowane  np.
poprzez monitoring za pomocą kamer.
Inną ważną rzeczą, jeśli nie najważniejszą, jest odpowiednie zabezpieczenie samego
komputera. Zabezpieczenie będzie dwustopniowe. Na początek zabezpieczamy BIOS,
póz
niej BootLoader  LILO. System Linux posiada kilka rodzajów programów urucho-
mieniowych, przy czym dwa z nich: LILO i GRUB są zdecydowanie najpopularniejsze.
Jednak ze względu na jasność konfiguracji oraz dużą elastyczność programu, bardziej
3.1. Dostęp bezpośredni 22
popularny i zwykle domyślnie instalowany (praktycznie w każdej dystrybucji Linuksa1),
jest bootloader LILO. Nim więc się zajmiemy.
3.1.1 BIOS
Jest kilka sposobów wystartowania komputera  z twardego dysku, dyskietki, płyty
CD, a w niektórych przypadkach przy użyciu obrazu startowego pobieranego bezpośred-
nio z sieci.
Uruchamianie systemu z dyskietki jest już dość rzadko spotykane i na dobrą sprawę
może przynieść więcej szkody niż pożytku  np. na dyskietce ratunkowej (tzw. rescue
disk) zmieści się nieporównanie mniej narzędzi diagnostycznych niż na płycie CD, nato-
miast z pewnością znajdzie się na dyskietce wystarczająco dużo miejsca, by uruchomić
system z odpowiednimi uprawnieniami.
Uruchamianie z CD, w opisywanej sytuacji, jest wygodne, ale tylko ze względu na
instalację systemu.
Rysunek 3.1: Kolejność uruchamiania systemu z urządzeń
Po instalacji zmieniamy ustawienia BIOS-u tak, aby system był uruchamiany z dysku
twardego. Takie ustawienie startu pozwoli nam na elastyczniejsze skonfigurowanie uru-
chamianego systemu (wykorzystamy do tego LILO).
Jak wygląda poprawne ustawienie kolejności wyboru urządzeń do uruchomienia sys-
temu widać na Rysunku 3.1
1
Biorę tutaj pod uwagę głównie najbardziej popularne dystrybucje.
3.1. Dostęp bezpośredni 23
Kolejną czynnością, jaką koniecznie trzeba wykonać po odpowiednim ustawieniu ko-
lejności  bootowania , jest ustawienie hasła na BIOS. Ustawia się dwa hasła  jedno
administratora, drugie hasła dostępu do komputera. Hasło administratora upoważnia do
wszelkich zmian w BIOS-ie, drugie pozwala na uruchomienie komputera w ogóle. Usta-
wienie hasła nie gwarantuje jednak całkowitego zabezpieczenia przed dostaniem się do
systemu.
Po pierwsze wiele BIOS-ów, jeśli nie wszystkie, posiada tzw. hasła serwisowe, które
mają ułatwić dostęp do komputera dla pracowników serwisu, np. w sytuacji, gdy właści-
ciel komputera zapomni hasła.
Niestety listy haseł serwisowych cały czas są dostępne w Internecie (niekoniecznie są
one legalne), stąd osoba niepowołana może mieć do nich dostęp. Drugi problem to płyta
główna. Użycie zworki czyszczącej BIOS, wyjęcie baterii z płyty spowoduje, że wszelkie
hasła ustawione w ten sposób zostaną usunięte.
Jak widać samo zabezpieczenie BIOS-u nie jest kompleksową ochroną komputera i
systemu. To działanie nie ma na celu uniemożliwienia dostępu, ale jedynie utrudnienie
go.
Radykalnym obejściem wszelkich zabezpieczeń jest fizyczne przełożenie dysku do
innego komputera. I w takiej sytuacji można np. dysk zamontować jako konkretną party-
cję z określonym systemem plików. Jedynym zabezpieczeniem przed takim atakiem jest
szyfrowanie partycji.
3.1.2 LILO
LILO, czyli LInux LOader, to standardowy program ładujący system operacyjny. Jest
to pierwszy, niewielki fragment kodu wykonywany zaraz po zakończeniu ładowania BIOS-
u. Zwykle, gdy użytkownik nie poda parametrów startowych do jądra systemu, LILO od-
czekuje określony czas (tzw. delay) i uruchamia domyślny system. W zależności od tego,
jak skonfigurujemy ten program, w taki sposób system będzie uruchamiany  możliwości
jest sporo  m.in. różne sposoby zabezpieczania hasłami, odpowiednie ustawienie czasu
oczekiwania, zablokowanie uruchamiania systemu z innych urządzeń niż twardy dysk.
Standardowa konfiguracja LILO, jaka jest tworzona w trakcie instalacji systemu, ma
postać taką, jaka jest pokazana na Listingu 3.1.
1 b o o t =/ dev / sda
2 r o o t =/ dev / sda3
3 i n s t a l l = / b o o t / boot -menu . b
3.1. Dostęp bezpośredni 24
4 map =/ b o o t / map
5 d e l a y =20
6 d e f a u l t = Linux
7 image =/ vmlinuz
8 l a b e l =Linux
9 read -o n l y
10 image =/ vmlinuz . o l d
11 l a b e l =LinuxOLD
12 read -o n l y
13 o p t i o n a l
Listing 3.1: Domyślna konfiguracja LILO
Główną wadą tej konfiguracji jest to, że nie jest ona zabezpieczona hasłami. Dzięki temu
każdy, bez większych problemów może podmienić parametry przekazywane do jądra,
takie jak np. położenie programu init, może też uruchomić system w trybie single  oba
podane przykłady są jednoznaczne ze zdobyciem uprawnień administratora. Wystarczy
przy starcie LILO, za pomocą klawisza [Shift] wejść w menu uruchamiania i wpisać:
linux init=/bin/sh rw
i system sam przekazuje nam uprawnienia administracyjne. Powyższy przykład dosko-
nale obrazuje Rysunek 3.2. Jak widać domyślna konfiguracja LILO nie jest bezpieczna.
Rysunek 3.2: Wykorzystanie niezabezpieczonego LILO
3.1. Dostęp bezpośredni 25
Logicznym rozwiązaniem problemu wydaje się zastosowanie haseł. Jest to dobry trop.
Można tę operację wykonać na dwa sposoby: globalnie bądz
lokalnie. Hasła lokalne
będą miały zasięg dla konkretnego, uruchamianego obrazu (w naszym przypadku Linux,
LinuxOLD), hasła globalne  dla całego systemu. Ustawienie hasła polega na wpisaniu w
odpowiednim miejscu słowa kluczowego password oraz po znaku równości samego hasła.
Dla hasła lokalnego będzie to w sekcji image=/vmlinuz, najlepiej po 9 linii, dla obrazu
Linux oraz analogicznie w sekcji image=/vmlinuz.old, po 12 linii, dla obraz LinuxOLD.
To rozwiązanie wydaje się być dość kłopotliwe  przy każdym uruchamianiu systemu
konieczne będzie wpisanie hasła. Nie jest to konieczne  wystarczy by hasło było wyma-
gane przy przekazywaniu parametrów do jądra. Uzyskamy to poprzez wpisanie w linii
poprzedzającej password=haslo słowa kluczowego restricted.
W tym momencie hasło jest wymagane tylko w sytuacji, gdy podawane są parametry
do jądra, w innym wypadku hasło nie będzie wymagane.
Jeżeli upłynie czas oczekiwania LILO (linia 5) delay=20, zostanie uruchomiony do-
myślny system operacyjny  hasła nie będą wymagane, ponieważ nie są podane parametry
rozruchowe. Przeprowadzone zmiany zobaczymy na Listingu 3.2
9 image =/ vmlinuz
10 l a b e l =Linux
11 r e s t r i c t e d
12 password = h a s l o
13 read -o n l y
14 image =/ vmlinuz . o l d
15 l a b e l =LinuxOLD
16 r e s t r i c t e d
17 password = h a s l o 1
18 read -o n l y
19 o p t i o n a l
Listing 3.2: Lokalne ustawienie haseł w LILO
Druga możliwość to globalne ustawienie hasła. Będzie ono wymagane przy próbie wy-
boru któregokolwiek z obrazów. Wstawiamy słowo kluczowe restricted do obszaru glo-
balnego  przed wszystkimi specyfikacjami obrazów. Zaraz po nim powinno się znalez
ć
password=hasło.
18 o t h e r =/ dev / fd0
19 l a b e l = f l o p p y
3.1. Dostęp bezpośredni 26
20 u n s a f e
21 o t h e r =/ dev / cdrom
22 l a b e l =cdrom
23 u n s a f e
Listing 3.3: Możliwość uruchomienia systemu z dyskietki i CD
Jeśli z jakichś względów bardziej pożądane jest zachowanie haseł różnych dla poszcze-
gólnych obrazów, należy dodać hasło do każdej specyfikacji systemu operacyjnego.
Pozostałaby możliwość uruchomienia systemu z dyskietki lub CDROM, gdyby w
pliku lilo.conf znalazły się linie z Listingu 3.3. W takiej sytuacji dobrym rozwiązaniem
jest umieszczenie parametru password=haslo w sekcji globalnej, restricted w lokalnej,
tak jak na Listingu 3.4.
W Listingu 3.3 pojawia się opcja unsafe. Ma ona na celu zapobieżenie dostępowi do
boot sektora podczas tworzenia mapy, wyłącza niektóre testy (np. test tablicy) partycji.
Opcja unsafe zapobiega potrzebie wkładania dyskietki do napędu przy każdym urucho-
mieniu instalatora mapy.
7 d e l a y =20
8 d e f a u l t = Linux
9 password = h a s l o
10 image =/ vmlinuz
11 l a b e l =Linux
12 read -o n l y
13 r e s t r i c t e d
14 image =/ vmlinuz . o l d
15 l a b e l =LinuxOLD
16 read -o n l y
17 o p t i o n a l
18 r e s t r i c t e d
19 o t h e r =/ dev / fd0
20 l a b e l = f l o p p y
21 u n s a f e
22 o t h e r =/ dev / cdrom
23 l a b e l =cdrom
24 u n s a f e
Listing 3.4: Zabezpieczenie czytnika dyskietek i CDROM w LILO
3.1. Dostęp bezpośredni 27
Na koniec pozostaje jeszcze zabezpieczenie samego pliku lilo.conf. Na nic się zda nawet
najwymyślniejsza konfiguracja programu, gdy każdy będzie mógł go otworzyć i podej-
rzeć jakie są ustawione hasła. Podejrzenie haseł w lilo.conf jest możliwe, ponieważ nie
są one w żaden sposób kodowane  podane są w czystej tekstowej postaci.
Nadajemy2 więc odpowiednie uprawnienia plikowi:
mab:~# chmod 600 /etc/lilo.conf
dzięki którym plik będzie mógł czytać tylko administrator systemu.
Druga czynność, którą należy wykonać, to zapobieżenie zmianom pliku. Można to
przeprowadzić za pomocą polecenia:
mab:~# chattr +i /etc/lilo.conf
W ten sposób tylko administrator, po wcześniejszym usunięciu flagi niezmienności może
zmienić zawartość tego pliku.
2
Uprawnienia można nadać tylko posiadając uprawnienia administratora.
Rozdział 4
Bezpieczna zdalna administracja
systemem
4.1 Telnet a SSH
Gdy mamy podłączony do sieci komputer, który w naszym przypadku jest serwerem,
można zarządzać nim zdalnie. Do wyboru mamy kilka możliwości połączenia się z takim
komputerem, najpopularniejsze z nich to: rlogin, Telnet i SSH. Jest to jednak wybór po-
zorny  transmisja za pomocą Telnetu i rlogin jest nieszyfrowana, czyli przesyłana otwar-
tym tekstem, za pomocą SSH  szyfrowana. Podsłuchanie transmisji nieszyfrowanej jest
sprawą bardzo prostą. Przykładowo z komputera o adresie IP 192.168.222.17 łączymy
się z serwerem o IP 192.168.222.19, za pomocą Telnetu. Kiedy już nastąpiło połączenie,
logujemy się jako root, następnie zmieniamy hasło i wylogowujemy się.
W tym samym czasie na serwerze włączony jest prosty analizator pakietów Ethereal,
który monitoruje cały ruch w podsieci. To, co wychwycił skaner pokazane jest na Listingu
4.1. Bez najmniejszego problemu Ethereal wychwycił wszystkie potrzebne dla potencjal-
nego włamywacza dane dotyczące komputera (system operacyjny i wersja jądra), a nawet
więcej  nazwa przypadkowego użytkownika, jego hasło oraz, w tym przypadku, najważ-
niejsze  hasło roota.
Wniosek jaki się nasuwa  używając nieszyfrowanej transmisji, np. poprzez najpo-
pularniejszy program Telnet oraz pozwalając na stosowanie takiego sposobu przesyłania
danych, dajemy dostęp do maszyny każdemu, kto tylko wykaże odrobinę wysiłku, by
uruchomić odpowiedni skaner sieci.
1 Debian GNU/ Linux 3 . 0 mab
2 mab l o g i n : i i z z a a ^M^@
4.1. Telnet a SSH 29
3 Password : t e s t ^M^@
4 L a s t l o g i n : Thu Dec 4 0 7 : 1 1 : 4 9 2 0 0 3
on t t y 1
5 Linux mab 2 . 4 . 1 8 - bf2 . 4 # 1 Son Apr
1 4 0 9 : 5 3 : 2 8 CEST 2 0 0 2 i 6 8 6 unknown
6 iza@mab : ~ $ s s u u ^M^@
7 Password : t e s t ^M^@
8 mab : / home / i z a # ppaasssswwdd ^M^@
9 E n t e r new UNIX password : t e s t ^M^@
10 Retype new UNIX password : t e s t ^M^@
11 passwd : password u p d a t e d s u c c e s s f u l l y
12 mab : / home / i z a # e e x x i i t t ^M^@
13 e x i t
14 iza@mab : ~ $
Listing 4.1: Zdobywanie hasła za pomocą Telnetu
Rozsądny administrator nie tyle, że zabroni dostępu do danego systemu przez Telnet, ale
także całkowicie usunie program (aplikację i serwer usługi) z systemu.
Przeprowadz
my ten sam test, ale zamiast Telnetu użyjemy SSH.
Na Rysunku 4.1 widać, że nastąpiło przesłanie pakietów, ale Ethereal już nie pokazał
nic więcej  transmisja była szyfrowana, czyli jakby na to nie patrząc bezpieczna. Pojawia
Rysunek 4.1: Próba skanowania transmisji SSH
4.2. Powłoka SSH 30
się pytanie, czy możliwe jest by transmisja prowadzona przez SSH była odszyfrowana?
Aby odpowiedzieć na to pytanie, należy zrozumieć jak działa samo SSH.
4.2 Powłoka SSH
4.2.1 Zasada działania powłoki SSH
Zasada działania powłoki jest bardzo podobna do transakcji internetowej typu SSL1.
Wpierw klient i serwer wymieniają publiczne klucze hostów. W sytuacji, gdy nigdy wcze-
śniej nie było połączenia między tymi hostami, to powłoka SSH zapyta, czy zaakceptować
klucz z niewiarygodnego z
ródła.
W następnym kroku klucze publiczne są wykorzystywane do negocjowania klucza
sesji. Ten zaś ma być używany do szyfrowania szyfrem blokowym2 wszystkich danych
w następującej po tym sesji.
Początkowa wymiana kluczy pomiędzy klientem i serwerem jest dla użytkownika nie-
widoczna, a użytkownik zostanie poproszony o zalogowanie się i uwierzytelnienie, do-
piero wtedy, gdy ustalanie szyfrowania sesji zostanie zakończone.
Uwierzytelnianie klienta przeprowadza się za pomocą certyfikatów RSA3 lub DSA4
(par kluczy). Jeśli klient posiada certyfikat, który jest rozpoznawany przez serwer, wtedy
użytkownik jest proszony przez swoje oprogramowanie klienta o wprowadzenie długiego
1
Secure Sockets Layer  zostało opracowane przez firmę Netscape, działa pomiędzy TCP/IP a innymi
protokołami, przy czym używa TCP/IP w imieniu innych protokołów, dzięki czemu możliwa jest uwierzy-
telnienie  klient  serwer oraz ustanowienie szyfrowanego połączenia. Zawiera w sobie dwa podprotokoły:
SSL record protocol  definiuje format używany do przesyłania danych oraz SSL handsnake protocol, który
używa SSL record protocol do wymiany komunikatów pomiędzy klientem i serwerem zaraz po nawiązaniu
połączenia.
2
Szyfr blokowy  to algorytm przekształcający porcję tekstu jawnego (niezaszyfrowanego) o określonej
długości na kryptogram (tekst zaszyfrowany) o tej samej długości, przy użyciu podanego przez użytkownika
tajnego klucza. Typowe wielkości przekształcanych na raz porcji danych (bloków) to 64 bity (8 bajtów) i
128 bitów (16 bajtów). Klasycznym przykładem szyfru o bloku 64-bitowym jest DES, zaś o bloku 128-
bitowym  AES.
3
RSA  posiada algorytm z kluczem publicznym, który nadaje się do szyfrowania oraz do podpisów
cyfrowych. Podejrzewa się [11], że odzyskanie chociaż 1 bitu z szyfrogramu otrzymanego przez zastoso-
wanie algorytmu RSA jest tak samo trudne jak odszyfrowanie dokładnie całego szyfrogramu. Stąd RSA
jest standardem uznanym praktycznie na całym świecie, a w USA był także opatentowany (patent wygasł
20 września 2000r).
4
DSA  posiada algorytm z kluczem publicznym, który może być stosowany tylko do podpisów cyfro-
wych  przy module 512 bitów nie jest wystarczająco silny, by zapewnić bezpieczeństwo, przy 1024 już
jest, ale wtedy jest znacznie wolniejszy niż RSA.
4.2. Powłoka SSH 31
hasła klucza prywatnego. Jeśli będzie ono wprowadzone poprawnie, to certyfikat zostaje
wykorzystany przez serwer do dokończenia uwierzytelniania  wyzwanie  odpowiedz
 ,
co jest dla serwera jednoznaczne z tym, że klient posiada klucz prywatny odpowiadający
kluczowi publicznemu umieszczonemu na serwerze.
Ważne w całym procesie jest to, że w żadnym momencie wymiany komunikatów mię-
dzy serwerem a klientem nie dochodzi do przesyłania przez sieć ani klucza publicznego,
odpowiadającego mu długiego hasła, ani jakiejkolwiek innej tajnej danej.
W przypadku, gdy uwierzytelnienie RSA/DSA nie uda się albo jeśli nie będzie certy-
fikatu uwierzytelniającego po stronie klienta, serwer zdalnie prosi o podanie standardo-
wego identyfikatora użytkownika oraz hasła poprawnego w zdalnym systemie. Nie ma
tutaj niebezpieczeństwa  w takim przypadku została już nawiązana zaszyfrowana sesja,
stąd kombinacja użytkownik  hasło przed wysłaniem zostały zaszyfrowane.
Ostatni krok to właściwa sesja, w której poprzez zaszyfrowany tunel uruchamiana jest
zdalna powłoka, bezpieczny transfer plików lub zdalne polecenie.
Jak widać rozszyfrowanie transmisji SSH jest praktycznie niemożliwe, choćby ze
względu na zastosowanie silnej kryptografii  klucze stosujące algorytmy RSA i DSA.
Gdyby jednak program deszyfrujący istniał, to czas oczekiwania na odszyfrowanie byłby
bardzo długi  wahał by się od kilku lat do paruset tysięcy lat.
4.2.2 Programy powłoki SSH
W gruncie rzeczy powłoka SSH to zbiór różnych narzędzi. Poniżej przedstawiam
najważniejsze z nich.
SSHD
To demon pełniący funkcję serwera dla wszystkich poleceń SSH. Konfigurować go
można poprzez plik /etc/ssh/sshd_config.
SSH
To główne narzędzie użytkownika SSH. Służy do pracy w zdalnej powłoce, wykony-
wania zdalnych poleceń oraz przekazywania portów.
SCP
Narzędzie do zdalnego kopiowania plików.
4.3. Dodatkowe opcje 32
SFTP
Narzędzie do interaktywnego transferu plików.
SSH-KEYGEN
Narzędzie do generowania kluczy prywatnych, które są wykorzystywane przy uwie-
rzytelnianiu RSA i DSA, w tym także kluczy hostów.
SSH-AGENT
Program, który  trzyma prywatne klucze używane do uwierzytelniania klientów RSA
lub DSA. Używa się go w tym celu, by tylko raz podawać hasła do kluczy. Przy kolejnych
logowaniach hasła nie będą już wymagane. Hasła są dodawane programem SSH-ADD.
SSH-ADD
Wczytuje klucz prywatny do procesu SSH-AGENT.
SSH-ASKPASS
Wyposaża polecenie SSH-ADD w interfejs X Window.
4.3 Dodatkowe opcje
Są dwa pliki konfiguracyjne, w których można ustawić dodatkowe opcje, aby po
pierwsze zwiększyć bezpieczeństwo, po drugie ułatwić trochę pracę na komputerze. Są
to: /etc/ssh/ssh_config i /etc/ssh/sshd_config.
4.3.1 Zdalne uruchamianie sesji X Window
Zdalne uruchamianie sesji X window jest bardzo przydatne, szczególnie, gdy narzę-
dzia które stosujemy do zarządzania systemem uruchamiają się właśnie w tym środo-
wisku. Opcja ta zaznaczana jest w obu plikach, w ssh_config jako ForwardX11 oraz
w sshd_config jako X11Forwarding. W obu przypadkach ustawiamy  yes . Należy
jednak pamiętać, że tutaj może znajdować się z
ródło potencjalnego ataku, np. próba prze-
chwycenia wciskanych klawiszy.
4.3. Dodatkowe opcje 33
4.3.2 Brak możliwości logowania jako root
Opcja w pliku sshd_config jakoPermitRootLogin. Opcja powinna być ustawiona
na  no . Niebezpieczne jest inne ustawienie tej opcji  jako superużytkownik administra-
tor powinien się logować z konta nieuprzywilejowanego (zwykłego użytkownika), np. po-
przez użycie poleceniasu. Zablokowanie tej opcji ma jeszcze dwie zalety. Po pierwsze,
aby uzyskać uprawnienia roota trzeba zalogować się jako zwykły użytkownik, a dopiero
póz
niej jako administrator  trzeba znać dwa hasła dostępu. Drugi powód to możliwość
kontrolowania, kto loguje się na konto root  z jakiego konta użytkownika nastąpiło logo-
wanie. Można to sprawdzić w pliku /var/log/auth.log. Ten plik domyślnie jest ustawiony
do odczytu tylko dla roota. Oczywiście należy liczyć się z tym, że osoba, która zdobyła
hasło roota, może wyedytować ten plik i zafałszować ślady obecności.
4.3.3 Logowanie za pomocą klucza
Już wspomniałam o tym, że do szyfrowania transmisji używane są klucze RSA i DSA.
Gdy zostanie zakłócone (bądz
domyślnie wyłączone w konfiguracji SSH) uwierzytelnie-
nie za pomocą kluczy stosowane jest  skrócone uwierzytelnianie parą identyfikator 
hasło.
Możliwe jest jednak takie skonfigurowanie systemu, by uwierzytelnianie odbywało
się tylko za pomocą kluczy.
Po pierwsze należy w konfiguracji /etc/ssh/sshd_config ustawić odpowiednie opcje.
Jeśli chcemy, by każdy użytkownik musiał logować się do systemu za pomocą klucza to
ustawiamy PasswordAuthentication na  no . Jednak takie postawienie sprawy
może sprawić wiele kłopotu, szczególnie z użytkownikami mniej zaawansowanymi.
Natomiast dobrym rozwiązaniem będzie konieczność logowania się kluczem jako
określony użytkownik. W takiej sytuacji ustawiamy opcjęPermitRootLoginna  with-
out-password  bez hasła.
Wpierw, z konta z którego będzie możliwość logowania się na konto root generujemy
klucz:
iza@:~$ ssh-keygen -tdsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/iza/.ssh/id_dsa):
oraz wprowadzamy hasło:
Enter passphrase (empty for no passphrase):
4.3. Dodatkowe opcje 34
Enter same passphrase again:
jako wynik otrzymujemy parę: klucz prywatny i publiczny oraz odcisk klucza.
Your identification has been saved in /home/iza/.ssh/id_dsa.
Your public key has been saved in /home/iza/.ssh/id_dsa.pub.
The key fingerprint is:
ad:5d:dd:25:34:0a:9f:d0:29:2e:f4:d7:d0:8b:e3:a9 iza@nb
iza@nb:~$
Stworzony plik z kluczem publicznym  id_dsa.pub kopiujemy na domyślny serwer i
kopiujemy jego zawartość do pliku authorized_keys:
iza@:~/.ssh$ scp id_dsa.pub
root@192.168.222.19:.ssh/authorized_keys
Nie można zapomnieć o tym, by plik .ssh/authorized_keys miał prawa dostępu tylko dla
roota.
#chmod 600 .ssh/authorized_keys
Spróbujmy zalogować się na konto root:
iza@nb:~$ ssh root@192.168.222.19
Enter passphrase for key  /home/iza/.ssh/id_dsa :
Last login: Thu Dec 4
13:53:41 2003 from 192.168.222.17 on NODEVssh
Linux mab 2.4.18-bf2.4
#1 Son Apr 14 09:53:28 CEST 2002 i686 unknown
Last login: Thu Dec 4
13:53:41 2003 from 192.168.222.17
mab:~#
Możliwość logowania z innego zdalnego konta, które nie posiada klucza prywatnego, od-
powiadającego kluczowi publicznemu umieszczonemu w pliku .ssh/authorized_key zo-
stała całkowicie zablokowana.
Dodatkowo można tak zabezpieczyć klucz publiczny w pliku .ssh/authorized_keys, by
logowanie przy pomocy odpowiadającego mu klucza prywatnego mogło odbyć się tylko
z określonego hosta. Robimy to poprzez dodanie do pliku .ssh/authorized_keys opcji
from= adres.ip .
4.4. Uwagi końcowe 35
4.4 Uwagi końcowe
Przy takim użyciu SSH zdalna praca w systemie staje się dużo bezpieczniejsza. Z jed-
nej strony pozwala uchronić użytkowników przed niekontrolowaną utratą haseł, z drugiej
 mobilizuje samego administratora do myślenia o bezpieczeństwie systemu, do spraw-
dzania, kto loguje się w systemie, kto używa prawnie bądz
bezprawnie uprawnień roota.
Rozdział 5
Hasła w systemie
Jednym z najważniejszych, choć bardzo podstawowym zabezpieczeniem każdego sys-
temu, nie tylko Linuksa, jest stosowanie haseł.
W rozdziale 3 wspominałam o hasłach dostępu do komputera. Ich zadaniem jest
niedopuszczenie do uruchomienia systemu przez nieuprawnioną osobę. Nie opisywałam
jednak jak powinny hasła wyglądać, gdzie są i gdzie powinny być przechowywane oraz w
jaki sposób następuje zdobywanie i łamanie haseł. W rozdziale 2.2 zostało opisane gdzie
są przechowywane hasła szyfrowane i nieszyfrowane, w jaki sposób są szyfrowane oraz
jaki algorytm wykorzystywany jest do szyfrowania haseł w Debianie.
W tym rozdziale zajmę się już samymi hasłami, ich zadaniem, bezpieczną postacią
oraz sposobami łamania haseł.
5.1 Bezpieczna postać haseł
Przy wybieraniu haseł należy pamiętać o kilku zasadach, które spowodują, że hasła
staną się silniejsze, a przez to bezpieczniejsze. Po pierwsze nie powinno się stosować
do zabezpieczania haseł w jakikolwiek sposób związanych z własną osobą, np. daty
urodzin swojej, kogoś z najbliższego otoczenia, imienia swojego, bliskich osób, imienia
ulubionego zwierzęcia, czy też postaci filmowej czy książkowej, a także te same słowa
ale pisane w odwrotnej kolejności  te hasła są bardzo łatwe do rozszyfrowania i to bez
użycia skomplikowanego programu deszyfrującego. Nie powinno się używać, tzw. haseł
słownikowych  programy deszyfrujące w pierwszej kolejności będą sprawdzały słowniki.
Co więcej, dodanie cyfr do imienia, pseudonimu czy do innego słowa cyfr (szczegól-
nie numeru telefonu, daty urodzin, czy innych znanych sobie numerów) nie spowoduje,
5.1. Bezpieczna postać haseł 37
że hasło będzie silniejsze  programy do łamania haseł są pisane w taki sposób, że do
określonego tekstu dodawane są sekwencje cyfr.
Dobre, silne hasło to hasło bardzo nietypowe. Nie znajduje się w słownikach, ale
jednocześnie jest proste do zapamiętania. Zbyt trudne do zapamiętania hasło prawdopo-
dobnie będzie zapisane na kartce i umieszczone w łatwo dostępnym miejscu, co ułatwi
jego zdobycie.
Najdoskonalszym hasłem są po prostu przypadkowo wybrane znaki. Trudność w sto-
sowaniu ich polega na tym, że są praktycznie niemożliwe do zapamiętania.
Pamiętając, że przy stosowanych w Debianie hasłach MD5 nie jest ważna maksy-
malna ilość znaków (ważna jest minimalna ilość znaków  hasło staje się znacznie silniej-
sze przy co najmniej 15 znakach), jak w hasłach DES (maksymalnie 8 znaków), dobrym
sposobem na silne hasło będzie długie zdanie, ale zamiast całych słów zapisujemy tylko
pierwsze ich litery, ze zmianą przynajmniej dwóch na jakieś inne znaki.
Na koniec dwie uwagi. Po pierwsze nie należy używać zdań zbyt osobistych do two-
rzenia haseł. Osoba, która będzie chciała zdobyć hasło z pewnością będzie korzystać z
inżynierii społecznej  m.in. będą próbowały poznać danego człowieka.
Po drugie nie należy stosować tych samych haseł na różnych komputerach. Pierwsze
co zrobi włamywacz posiadający hasło do danego komputera, to sprawdzi, czy dane hasło
nie pasuje gdzieś jeszcze.
5.1.1 Wymuszanie stosowania bezpiecznych haseł
Dobrym, choć trochę brutalnym sposobem na silne hasła w systemie jest zmuszenie
wszystkich użytkowników do tego, by takowe hasła stosowali. Można to zrobić poprzez
użycie odpowiedniego narzędzia, którego zadaniem będzie odrzucanie złych (słabych)
haseł. Niestety, system Debian nie ma specjalnie przeznaczonych dla niego programów
wykonujących powyższe zadania. Pewnym rozwiązaniem będzie uruchomienie progra-
mów polecanych przez [10]  Passwd+, Npasswd, Anlpasswd. Nie mniej Debian posiada
narzędzie do kontrolowania jakości haseł. To moduł PAM.
5.1.2 Hasła jednorazowe
Hasła jednorazowe, jak sama nazwa wskazuje, są metodą wykorzystującą system, w
którym dane hasło będzie przez użytkownika użyte tylko jeden raz. Nawet jeśli takie
hasło zostanie przechwycone, to nic nie zmienia w bezpieczeństwie systemu  hasło jest
5.2. Moduł PAM 38
ważne tylko dla tej jednej aktualnej sesji i prawdopodobieństwo, że hasło się powtórzy
jest nikłe.
5.2 Moduł PAM
PAM, czyli Pluggable Authentication Modules, umożliwia administratorom systemu
wybrać sposób, w jaki programy będą uwierzytelniać użytkowników.
W skład narzędzia wchodzą:
" biblioteki systemowe używane przez usługi, czyli standardowe programy linuk-
sowe takie, jak passwd czy login;
" moduły, które wykonują poszczególne zadania składające się na procedurę weryfi-
kacji;
" dane konfiguracyjne, które określają jakie czynności weryfikacyjne dla danej usługi
należy uruchomić;
" dodatkowe konfiguracje wymagane przez niektóre moduły PAM.
5.2.1 Zasada działania
Zasadę działania opiszę na przykładzie konfiguracji usługi su.
Typowy plik konfiguracyjny tej usługi jest pokazany na Listingu 5.1.
1 a u t h s u f f i c i e n t pam_rootok . so
2 a u t h r e q u i r e d pam_wheel . so
3 a u t h r e q u i r e d pam_unix . so shadow n u l l o k
4 a c c o u n t r e q u i r e d pam_unix . so
5 password r e q u i r e d pam_unix . so
6 s e s s i o n r e q u i r e d pam_unix . so
Listing 5.1: Domyślna konfiguracja PAM dla usługi su
Wpisy  auth używane są do określenia wartości atrybutów kont użytkowników oraz
stosowania elementów sterujących kontami.  Password używane, gdy zmieni się hasło
dla bieżącej usługi. Wpisy  session są wykorzystywane na potrzeby rejestrowania usługi
syslog. Grupy wpisów używane są po kolei, w związku z czym tworzą stos. Tutaj mamy
stos trzech wpisów  auth oraz po jednym wpisie dla pozostałych typów.
5.2. Moduł PAM 39
Druga część polecenia to słowo kluczowe, które określa w jaki sposób wynik danego
modułu wpłynie na rezultat całej weryfikacji. Słowo kluczowe może mieć jedną z czte-
rech postaci:
" sufficient  wystarczający; gdy ten moduł przyzna użytkownikowi dostęp, PAM po-
minie wszystkie pozostałe moduły ze stosu i zwróci usłudze wartość informującą,
że weryfikacja się powiodła;
" requisite  konieczny; gdy ten moduł odmówi dostępu użytkownikowi, PAM zwróci
wartość, informującą o niepowodzeniu w weryfikacji, tym samym wszystkie pozo-
stałe moduły ze stosu zostaną pominięte;
" required  wymagany; ten moduł musi przyznać dostęp, aby cała procedura wery-
fikacji mogła zakończyć się powodzeniem;
" optional  opcjonalny; wynik tego moduły będzie brany pod uwagę, gdy żaden inny
nie da rozstrzygającego wyniku.
Trzecie pole wpisu to ścieżka do wybranego modułu. W Debianie wygląda to w ten spo-
sób, natomiast w innym systemie przykładowo może mieć postać /lib/security/pam_root-
ok.so. Natomiast po ścieżce następują wymagane bądz
opcjonalne argumenty modułu.
Kiedy już wiemy jak wygląda plik, widzimy jak przebiega procedura weryfikacji.
Po pierwsze, gdy użytkownik wpisze polecenie su, to do sprawdzenia czy ma prawo je
wykonać konieczne są trzy moduły. Pierwszy moduł to rootok.so, który na podstawie
rzeczywistego identyfikatora sprawdza, czy użytkownik jest superużytkownikiem. Jeśli
jest to, ze względu na słowo kluczowe sufficient, kończy działanie  superużytkownik
nie musi podawać hasła aby wykonać polecenie su. Gdy odpowiedz
będzie negatywna,
proces weryfikacji trwa dalej  pam_wheel.so sprawdza, czy dany użytkownik należy do
grupy, która może logować się na konto root, zwraca odpowiednią wartość, a przez to
ogranicza dostęp do polecenia na poziomie grup.
Moduł pam_unix.so to kolejny krok procedury  żąda hasła dopuszczającego do po-
leceniasui sprawdza je. Zostaje zwrócona odpowiednia wartość w zależności od tego,
czy weryfikacja powiodła się czy nie. W tym miejscu na listingu widać dodatkowe opcje
 argumenty. shadow informuje o tym, że zostaje wykorzystany plik haseł /etc/shadow
oraz nullok, który mówi o tym, że konto docelowe może mieć puste hasło  pominięcie
tego argumentu spowoduje odrzucanie wszystkich kont nie posiadających haseł.
Kolejne trzy wpisy wywołując ten sam moduł (pam_unix.so) określają stan konta i
5.2. Moduł PAM 40
hasła użytkownika docelowego. Wpis dotyczący sesji generuje wpis usługi syslog dla
tego wywołania polecenia su.
5.2.2 Weryfikacja haseł podczas ich wybierania
Do weryfikacji haseł podczas ich wybierania przydatny jest moduł pam_cracklib.so,
który domyślnie sprawdza i porównuje dane hasło z każdym słowem zawartym w słow-
niku /usr/lib/cracklib_dict. Jednocześnie ma za zadanie sprawdzić, czy dane hasło nie jest
palindromem, prostym przekształceniem danego słownikowego słowa, rotacją lub zmianą
wielkości znaków. Dodatkową zaletą tego modułu jest to, że porównuje on bieżące hasło
z listą haseł wcześniej podanych przez użytkownika. Lista ta przechowywana jest w pliku
/etc/security/opasswd.
Argumenty, jakie mogą definiować ten moduł, to m.in. retry=n  określa liczbę prób
przy wyborze nowego hasła, domyślnie wartość n=1; minlen=n  minimalna długość łań-
cucha znaków, domyślnie n=10, wartość ta powinna być co najmniej równa wielkości
n; ucredit=u, lcredit=l, dcredit=d, ocredit=o  maksymalna  waga długości dla liter
wielkich, małych, cyfr i innych proponowanych znaków, domyślnie wartość dla każdego
wynosi 1. Przykładowo mamy ustawioną długość hasła na n=20, wtedy ustawiamy war-
tości u=5, l=5, d=5 i o=5.
Jeszcze jeden przykład jest pokazany na listingu 5.2.
1 password r e q u i r e d p a m _ c r a c k l i b . so r e t r y = 3
minlen =12 o c r e d i t = 2 d c r e d i t = 2 d i f o k =3
Listing 5.2: Przykład konfiguracji modułu pam_cracklib.so
Użytkownik może wykonać 3 próby na wybranie określonego hasła  retry=3, hasło musi
mieć minimalną długość 12 znaków  minlen=12, w którym każdy znak liczy się jako 1,
a każde dwie cyfry (dcredit=2) i dwa znaki niealfanumeryczne (ocredit=2) zwiększają
długość o kolejną wartość 1. Stąd hasło musi mieć co najmniej 7 znaków oraz zawierać
dwie cyfry i dwa znaki niealfanumeryczne. Hasła składające się tylko z dużych i małych
liter muszą zawierać co najmniej 10 znaków.
Opcja difok=3 mówi, odnosząc się do starych haseł, że trzy znaki z nowego hasła nie
mogły wystąpić w starym haśle.
5.4. Inżynieria społeczna  jak nie używając komputera zdobyć hasło? 41
5.3 Wymuszanie regularnych zmian hasła
Jeśli hasło jest silne, jest duże prawdopodobieństwo, że nie zostanie złamane. A
a-
manie hasła mocnego jest zadaniem długotrwałym. Stąd pojawia się postulat, by hasła
mimo, że wcześniej wymuszane jako hasła silne powinny być okresowo zmieniane, by
uniknąć włamania.
Okresowe wymuszenie zmiany hasła można ustawić korzystając z polecenia passwd
uzupełnionego o dodatkowe opcje:
" -x  określa maksymalną ilość dni, przez jaką hasło będzie ważne, po tym czasie
hasło musi być zmienione;
" -w  określa liczbę dni, przez którą użytkownik będzie otrzymywał informację o
konieczności zmiany hasła (na określoną liczbę dni przed upływem terminu waż-
ności);
" -n  określa minimalną ilość dni, przez którą hasło nie może być zmienione;
" -i  po określonej ilości dni od wygaśnięcia hasła następuje wyłączenie konta.
Jeśli chcemy natychmiast przeterminować konto, wtedy używamy opcję -e, która wymusi
na użytkowniku zmianę hasła zaraz po najbliższym zalogowaniu.
Za dobry pomysł uważa się [10] wymuszanie zmiany hasła co ok 90 dni. Często
bywa tak, że data zmiany hasła ustawiana jest na zmianę pór roku, czyli na 21 marca, 21
czerwca, 21 września i 21 grudnia.
5.4 Inżynieria społeczna  jak nie używając komputera
zdobyć hasło?
Wbrew pozorom nie trzeba mieć dostępu do konkretnego komputera, by zdobyć hasło
do komputera. Wystarczy dostęp do jego otoczenia, do biurka użytkownika.
Bardzo często jest tak, że administrator wymaga określonej jakości hasła dostępu,
którego zwykły użytkownik nie jest w stanie zapamiętać, w wyniku czego hasło zostaje
zapisane na kartce i najczęściej powieszone w widocznym miejscu  żeby go nie zapo-
mnieć .
Jedną z pierwszych rzeczy, którą wykona potencjalny włamywacz, gdy będzie mieć
bezpośredni dostęp do komputera, to sprawdzenie, czy nie ma powieszonej kartki z ha-
5.5. A
amanie haseł 42
słami, czy na biurku nie leży jakiś notes. Stąd kolejny postulat, z jednej strony do ad-
ministratorów, by ustalali wymagania co do haseł na poziomie możliwości poznawczych
użytkowników, do użytkowników zaś, by mimo wszystko próbowali zapamiętać hasła i
nie zapisywali ich.
5.5 A
amanie haseł
A
amanie haseł to działanie polegające na próbie odgadywania haseł, by w ten sposób
otrzymać dostęp do komputera. Najpopularniejszą strategią łamania haseł jest metoda
słownikowa  wybierane są często używane słowa zawarte w słowniku oraz określone
wzory stosowanych haseł. Włamywacz będzie chciał zdobyć plik /etc/passwd lub w przy-
padku przesłaniania haseł plik /etc/shadow, a następnie, z dużym prawdopodobieństwem,
zdalnie uruchomi program zgadujący hasła z danego komputera.
Drugi sposób to wykorzystanie kolejnych prób zalogowania się. Zostaje wykorzy-
stana nazwa użytkownika, np. root, a następnie zaczynają się próby odgadnięcia hasła,
np. zaczynając od określonego ciągu znaków aaaaaa, zmieniając kolejne literki, np.
aaaaab. Ten sposób wymaga ogromu cierpliwości i wystarczająco dużo czasu. Ta me-
toda ma ogromną wadę  pozostawia ślad w plikach protokołowania (tzw. logach), które
administrator systemu powinien dość często sprawdzać. Pozostawione ślady znajdują się
w pliku /var/log/messages, a przykładowa zawartość pliku jest pokazana na Listingu 5.3
1 Dec 9 0 4 : 3 5 : 0 6 mab l o g i n [ 7 6 1 ] : FAILED LOGIN
( 2 ) on  t t y 1  FOR  r o o t  , A u t h e n t i c a t i o n
f a i l u r e D e c 9 0 4 : 3 5 : 1 1 mab l o g i n [ 7 6 1 ] : TOO
MANY LOGIN TRIES ( 3 ) on  t t y 1  FOR  r o o t 
2 Dec 9 0 4 : 3 5 : 1 1 mab PAM_unix [ 7 6 1 ] : ( l o g i n )
s e s s i o n c l o s e d f o r u s e r r o o t
3 Dec 9 0 4 : 3 5 : 1 1 mab PAM_unix [ 7 6 1 ] : 2 more
a u t h e n t i c a t i o n f a i l u r e s ; LOGIN( u i d =0) - >
r o o t f o r l o g i n s e r v i c e
Listing 5.3: Przykładowa zawartość pliku /var/log/auth.log
Ręczne przeprowadzanie ataku słownikowego nie bardzo ma sens i mało kto ma tyle
cierpliwości by go przeprowadzać, stąd powstały programy automatyzujące ataki z wy-
korzystaniem słownika.
5.5. A
amanie haseł 43
5.5.1 Crack
To najpopularniejszy program napisany specjalnie do łamania haseł w systemach
UNIX, wykorzystuje do ich generowania słowa z elektronicznego słownika.
Crack otwiera po kolei wszystkie pliki katalogu, a następnie stosuje do zawartych
w nim słów każdą regułę z różnych zbiorów plików rules w podkatalogu run i sprawdza,
czy każde przekształcone słowo nie pasuje do któregoś z niezłamanych jeszcze haseł użyt-
kowników. Jeśli je dopasuje, wyświetla w wyniku wersję złamaną i wersję zakodowaną
hasła.
Gdy Crack zastosuje jedną regułę do każdego słowa ze słownika i każdego hasła,
przechodzi do następnej reguły, a następnie do kolejnego słownika, aż zostaną wyczer-
pane wszystkie możliwości lub złamane wszystkie hasła.
Same reguły określają przekształcenia, jakie program ma wykonać na słowach znaj-
dujących się w słowniku. Zapisane są w typowym dla Cracka metajęzyku.
Przykładowo reguła !?Al sprawi, że program będzie wybierał słowa złożone z sa-
mych liter alfabetu i zanim spróbuje je jako hasła, ma zapisać je małymi literami; reguła
>7!?Alx05$9$9  program wybierze słowa, które mają co najmniej 7 znaków i za-
wierają tylko litery alfabetu, potem zapisze je małymi literami, następnie wybierze z nich
pierwsze 6 znaków i doda na końcu  99 .
Metajęzyk Cracka pozwala w łatwy sposób dostosować odpowiadające danej osobie
reguły.
5.5.2 John the Ripper
Ten program jest znacznie nowszy od programu Crack, jest zdecydowanie szybszy i
posiada kilka dodatkowych funkcji.
Po pierwsze łamie hasła standardowe i algorytmy o podwójnej długości DES i MD5.
Po drugie raz rozpoczętą sesję  łamania można przerwać i póz
niej ponownie wznowić.
Ten program jest dostępny dla różnych platform systemowych, nie tylko dla Linuksa,
przez co może być uruchomiony w danym systemie, proces zostanie przerwany, po czym
wznowiony na innym systemie.
Podobnie jak w Cracku można określić swoją własną listę stosowanych słów i reguł.
Uruchomienie programu jest proste:
mab:~# unshadow /etc/passwd /etc/shadow > passwd.txt
mab:~# chmod 600 passwd.txt
mab:~# john passwd.txt
5.6. Środki zaradcze 44
W efekcie otrzymamy spis haseł, taki jak na Listingu 5.4  jak widać złamanie typowych,
prostych haseł nie sprawiło najmniejszego problemu programowi.
1 r o o t : t e s t : 0 : 0 : r o o t : / r o o t : / b i n / bash
2 i i i : i i i i : 1 0 0 1 : 1 0 0 1 : , , , : / home / i i i : / b i n / bash
3 jam : jam : 1 0 0 2 : 1 0 0 2 : , , , : / home / jam : / b i n / bash
4
5 3 p a s s w o r d s cr a c k e d , 2 l e f t
Listing 5.4: Rezultat działania programu John the Ripper
Program może działać w kilku trybach:
" Tryb listy słów  umożliwia określenie listy słów w postaci pliku bądz
listy odczy-
tywanej ze standardowego wejścia; słowa będą używane podczas próby złamania
haseł;
mab:~# john -wordfile:FILE
mab:~# john -wordfile -stdin
" Tryb pojedynczego przejścia  wykorzystuje informacje logowania jako hasła;
mab:~# john -single
" Tryb przyrostowy  wypróbowuje wszystkie możliwe kombinacje znaków; jest to
najsilniejszy tryb, ale jednocześnie najwolniejszy;
mab:~# john -incremental
" Tryb zewnętrzny  umożliwia zewnętrznym definicjom trybów stosowanie funkcji
napisanych w językach zbliżonych do C;
mab:~# john - external
5.6 Środki zaradcze
Crack i John the Ripper to dwa najpopularniejsze programy, tym niemniej w Interne-
cie można znalez
ć niezliczoną ilość programów do łamania haseł  jakby nie było każdy
włamywacz na swój ulubiony program, najczęściej własnoręcznie napisany.
Aby zapobiec zbyt łatwemu złamaniu haseł administrator powinien samodzielnie te-
stować słabe hasła, powinien być pewnym, że hasła w plikach nie dają się odczytywać.
Często powinny być sprawdzane pliki protokołowania (tzw. logi).
Rozdział 6
Ataki
Atak  to agresywne działanie przeciw komuś (lub czemuś) przy użyciu siły fizycz-
nej lub broni; napaść, natarcie; ostre, często nieprzebierające w środkach, wystąpienie
1
przeciw komuś albo czemuś .
Atakowanie systemu komputerowego będzie miało znaczenie podobne, do uogólnio-
nego  będzie to działanie na niekorzyść danego systemu, próba zniszczenia go, przejęcia
władzy nad systemem, itd. Ten rozdział opisuje sposoby atakowania systemu oraz podaje
recepty jak się przed nimi bronić.
6.1 Omiatanie
Omiatanie systemu i sieci to próba zdobycia jak największej ilości informacji o dzia-
łającym systemie i sieci, w której on pracuje. Można to robić na wiele sposobów, ale cel
hakera jest jeden  zdobyć jak najwięcej informacji o systemie, o jego otoczeniu.
6.1.1 Nmap
Najpopularniejszymi sposobami zdobywania informacji jest tzw. omiatanie i skano-
wanie. Omiatanie, czyli tzw.  pingowanie 2 ma za zadanie określenie ile komputerów jest
w określonej sieci, czy dany komputer w sieci jest właśnie podłączony, jaka jest jakość
połączenia. Nmap to narzędzie skanujące do wielu zastosowań, które posiada wbudowane
omiatanie poleceniem ping. Należy mu podać tylko listę adresów lub sieci i podać jako
argument opcje-sP. Efekt takiego omiatania widać na Listingu 6.1.
1
Słownik języka polskiego, http://slowniki.onet.pl
2
Nazwa bierze się od programu omiatającego Ping
6.1. Omiatanie 46
1 Host ( 1 9 2 . 1 6 8 . 2 2 2 . 0 ) seems t o be a s u b n e t
b r o a d c a s t a d d r e s s ( r e t u r n e d 1 e x t r a p i n g s ) .
2 Host ( 1 9 2 . 1 6 8 . 2 2 2 . 1 ) a p p e a r s t o be up .
3 Host ( 1 9 2 . 1 6 8 . 2 2 2 . 1 7 ) a p p e a r s t o be up .
4 Host ( 1 9 2 . 1 6 8 . 2 2 2 . 1 9 ) a p p e a r s t o be up .
5 Host ( 1 9 2 . 1 6 8 . 2 2 2 . 2 5 5 ) seems t o be a s u b n e t
b r o a d c a s t a d d r e s s ( r e t u r n e d 2 e x t r a p i n g s ) .
6 Nmap run c o m p l e t e d - - 256 IP a d d r e s s e s ( 3 h o s t s
up ) s c a n n e d i n 4 s e c o n d s
Listing 6.1: Efekt omiatania programem Nmap
W ten prosty sposób zostały podane informacje: ile jest aktywnych hostów w sieci, do-
kładnie jakie są ich adresy IP oraz czas skanowania  jak szybka jest ta sieć.
6.1.2 Zapobieganie omiataniu
Niepożądane jest zezwolenie na omiatanie sieci spoza sieci lokalnej. Globalnie można
to zablokować zmieniając wartość0w pliku /proc/sys/net/ipv4/icmp_echo_ignore_all na
1. Nie można jednak zapominać, że omiatanie samo w sobie posiada ogromną zaletę 
pozwala administratorowi diagnozować sieć. I dobrze by było, gdyby można tak skonfi-
gurować możliwość omiatania, nawet z zewnątrz by była bezpieczna. Niebezpieczeństwo
w tym wypadku związane jest nie tylko z możliwością określenia zawartości sieci, ale
także skutecznego zapchania jej pakietami. Aby zapobiec zapychaniu wykorzystujemy
iptables, jak na Listingu 6.2.
1 mab : ~ # i p t a b l e s -A INPUT -p ICMP - i e t h 0 --icmp
-t y p e echo-r e q u e s t -m LIMIT -- l i m i t 1 / m i n u t e
- j ACCEPT
Listing 6.2: Ograniczanie częstotliwości omiatania
I tutaj-A INPUTdodajemy nowy łańcuch do INPUT,-p ICMPnazwa ograniczanego
protokołu  ICMP,--icmp-type echo-request rodzaj komunikatu ICMP  żą-
danie odpowiedzi, -i  interfejs który jest ograniczany  eth0, -m LIMIT --limit
1/minute 1 pakiet ICMP jest wpuszczany w ciągu jednej minuty.
6.2. Usługi systemu operacyjnego podatne na atak 47
6.2 Usługi systemu operacyjnego podatne na atak
Usługi w systemie operacyjnym są najbardziej podatne na ataki z zewnątrz, gdyż są
przeznaczone do zdalnej komunikacji z innymi systemami. Wiele z nich może stać się
ofiarą przepełnienia bufora czy też innych luk w zabezpieczeniach.
6.2.1 Skanowanie portów  identyfikacja usług
Aby dowiedzieć się jakie usługi są uruchomione w systemie operacyjnym, należy
przeskanować jego porty  otwarte porty prowadzą nasłuch. Duża część portów jest uru-
chamiana na ogólnie zdefiniowanych portach, np. SSH  22, http  80. Do zdalnego
określenia otwartych portów wykorzystamy ponownie program Nmap (Listing 6.3), do
lokalnego  Netstat (Listing 6.4).
1 mab : ~ # nmap -sTU -O l o c a l h o s t
2 I n t e r e s t i n g p o r t s on mab ( 1 2 7 . 0 . 0 . 1 ) :
3 P o r t S t a t e S e r v i c e
4 9 / t c p open d i s c a r d
5 9 / udp open d i s c a r d
6 1 3 / t c p open d a y t i m e
7 2 1 / t c p open f t p
8 2 2 / t c p open s s h
9 2 3 / t c p open t e l n e t
10 3 7 / t c p open time
11 5 3 / t c p open domain
12 5 3 / udp open domain
13 6 8 / udp open d h c p c l i e n t
14 8 0 / t c p open h t t p
15 1 1 0 / t c p open pop-3
16 1 1 1 / t c p open s u n r p c
17 1 1 1 / udp open s u n r p c
18 1 1 3 / t c p open a u t h
19 1 3 7 / udp open n e t b i o s -ns
20 1 3 8 / udp open n e t b i o s -dgm
21 1 3 9 / t c p open n e t b i o s -s s n
22 1 4 3 / t c p open imap2
23 2 2 0 / t c p open imap3
6.2. Usługi systemu operacyjnego podatne na atak 48
24 5 1 5 / t c p open p r i n t e r
25 7 9 9 / udp open unknown
26 8 0 0 / udp open mdbs_daemon
27 9 2 1 / udp open unknown
28 9 5 3 / t c p open r n d c
29 9 9 1 / udp open unknown
30 9 9 2 / udp open unknown
31 9 9 6 / udp open v s i n e t
32 9 9 7 / udp open m a i t r d
33 9 9 8 / udp open pup arp
34 9 9 9 / udp open a p p l i x
35 32770/ udp open sometimes-r p c 4
36 32771/ udp open sometimes-r p c 6
37 32773/ udp open sometimes-r p c 1 0
38 32774/ udp open sometimes-r p c 1 2
Listing 6.3: Skanowanie portów za pomocą programu Nmap
1 mab : ~ # n e t s t a t - anp
2 A c t i v e I n t e r n e t c o n n e c t i o n s
3 P r o t o L o ca l Address PID / Program name
4 t c p 0 . 0 . 0 . 0 : 3 2 7 6 8 3 1 3 / r p c . s t a t d
5 t c p 0 . 0 . 0 . 0 : 5 1 5 3 6 3 / l p d
6 t c p 0 . 0 . 0 . 0 : 3 7 3 2 4 / i n e t d
7 t c p 0 . 0 . 0 . 0 : 9 3 2 4 / i n e t d
8 t c p 0 . 0 . 0 . 0 : 1 3 9 3 7 2 / smbd
9 t c p 0 . 0 . 0 . 0 : 1 3 3 2 4 / i n e t d
10 t c p 0 . 0 . 0 . 0 : 1 1 0 3 2 4 / i n e t d
11 t c p 0 . 0 . 0 . 0 : 1 4 3 3 2 4 / i n e t d
12 t c p 0 . 0 . 0 . 0 : 1 1 1 1 6 1 / portmap
13 t c p 0 . 0 . 0 . 0 : 8 0 4 3 8 / apache
14 t c p 0 . 0 . 0 . 0 : 1 1 3 3 2 4 / i n e t d
15 t c p 0 . 0 . 0 . 0 : 2 1 3 2 4 / i n e t d
16 t c p 1 9 2 . 1 6 8 . 2 2 2 . 1 9 : 5 3 2 9 6 / named
17 t c p 1 2 7 . 0 . 0 . 1 : 5 3 2 9 6 / named
18 t c p 0 . 0 . 0 . 0 : 2 2 3 7 8 / s s h d
6.2. Usługi systemu operacyjnego podatne na atak 49
19 t c p 0 . 0 . 0 . 0 : 2 3 3 2 4 / i n e t d
20 t c p 1 2 7 . 0 . 0 . 1 : 9 5 3 2 9 6 / named
21 t c p 0 . 0 . 0 . 0 : 2 2 0 3 2 4 / i n e t d
22 udp 0 . 0 . 0 . 0 : 3 2 7 6 8 2 9 6 / named
23 udp 0 . 0 . 0 . 0 : 3 2 7 6 9 3 1 3 / r p c . s t a t d
24 udp 0 . 0 . 0 . 0 : 3 2 7 7 0 3 0 3 / l w r e s d
25 udp 0 . 0 . 0 . 0 : 3 2 7 7 1 3 9 2 / s f s c d
26 udp 0 . 0 . 0 . 0 : 3 2 7 7 3 -
27 udp 1 2 7 . 0 . 0 . 1 : 3 2 7 7 4 3 9 6 / s f s r w c d
28 udp 1 9 2 . 1 6 8 . 2 2 2 . 1 9 : 1 3 7 3 7 0 / nmbd
29 udp 0 . 0 . 0 . 0 : 1 3 7 3 7 0 / nmbd
30 udp 0 . 0 . 0 . 0 : 9 3 2 4 / i n e t d
31 udp 1 9 2 . 1 6 8 . 2 2 2 . 1 9 : 1 3 8 3 7 0 / nmbd
32 udp 0 . 0 . 0 . 0 : 1 3 8 3 7 0 / nmbd
33 udp 1 2 7 . 0 . 0 . 1 : 9 2 1 3 0 3 / l w r e s d
34 udp 0 . 0 . 0 . 0 : 7 9 9 -
35 udp 0 . 0 . 0 . 0 : 8 0 0 -
36 udp 1 9 2 . 1 6 8 . 2 2 2 . 1 9 : 5 3 2 9 6 / named
37 udp 1 2 7 . 0 . 0 . 1 : 5 3 2 9 6 / named
38 udp 0 . 0 . 0 . 0 : 6 8 1 5 7 / d h c l i e n t - 2 . 2 . x
39 udp 0 . 0 . 0 . 0 : 9 9 1 3 9 2 / s f s c d
40 udp 0 . 0 . 0 . 0 : 9 9 2 3 9 2 / s f s c d
41 udp 0 . 0 . 0 . 0 : 9 9 6 3 9 6 / s f s r w c d
42 udp 0 . 0 . 0 . 0 : 9 9 7 3 9 7 / n f s m o u n t e r
43 udp 0 . 0 . 0 . 0 : 9 9 8 3 9 6 / s f s r w c d
44 udp 0 . 0 . 0 . 0 : 9 9 9 3 9 7 / n f s m o u n t e r
45 udp 0 . 0 . 0 . 0 : 1 1 1 1 6 1 / portmap
Listing 6.4: Netstat  pobieranie informacji o tym, które porty w systemie są otwarte
Po bliższym przyjrzeniu się obu listingom można zauważyć, że oba programy podają do-
kładnie te same informacje  w tym dla nas najważniejszą  jest otwartych zbyt dużo por-
tów. Zbyt dużo usług jest niepotrzebnych (nie są przez nas celowo wykorzystywane). Cią-
gle należy pamiętać, że każdy niepotrzebnie otwarty port to potencjalny cel ataku. Jedna
z polityk bezpieczeństwa mówi, że dobrze jest zablokować wszystkie możliwe porty po-
przez wyłączanie niepotrzebnych usług, inna że lepiej blokować jest zaporą ogniową i
6.2. Usługi systemu operacyjnego podatne na atak 50
otwierać tylko te, które są niezbędne do poprawnego działania systemu. Uważam, że
pierwsza z wymienionych polityk bezpieczeństwa jest właściwszym rozwiązaniem nawet
dla niezbyt dużego systemu.
Na początek usuwamy usługi, których nie chcemy bądz
nie potrzebujemy w systemie.
Jakie procesy odpowiadają za otwarcie danego portu widać na listingu 6.4 w trzeciej
kolumnie. Przykładowo na liście usług znajdujemy linię:
tcp 0.0.0.0:32768 313/rpc.statd
Wpierw sprawdzamy do jakiego pakietu należy uruchomiony program:
mab:~# dpkg -S rpc.statd
nfs-common: /usr/share/man/man8/rpc.statd.8.gz
nfs-common: /sbin/rpc.statd
Widać, że program należy do pakietu nfs-common. Teraz sprawdzamy do czego służy ten
pakiet (Listing 6.5).
1 mab : ~ # apt -cache show n f s -common
2 [ . . . ]
3 D e s c r i p t i o n : NFS s u p p o r t f i l e s common t o c l i e n t
and s e r v e r Use t h i s package on any machine
t h a t does NFS e i t h e r a s c l i e n t o r s e r v e r .
Programs i n c l u d e d : lockd , s t a t d , showmount
, and n f s s t a t .
Listing 6.5: Sprawdzanie informacji o pakiecie
Po opisie widać, że jest to usługa NFS, której w systemie nie planowaliśmy uruchamiać.
Zatem najprościej będzie w tym wypadku usunąć usługę poprzez usunięcie pakietu (Li-
sting 6.6).
1 mab : ~ # apt -g e t remove n f s -common
2 Reading Package L i s t s . . . Done
3 B u i l d i n g Dependency Tree . . . Done
4 The f o l l o w i n g p a c k a g e s w i l l be REMOVED:
5 libpam-s f s nfs -common nfs -k e r n e l -s e r v e r s f s -
c l i e n t s f s -common
6 Do you want t o c o n t i n u e ? [ Y/ n ] y
7 Removing libpam-s f s . . .
6.2. Usługi systemu operacyjnego podatne na atak 51
8 Removing nfs -k e r n e l -s e r v e r . . .
9 S t o p p i n g NFS k e r n e l daemon : mountd n f s d .
10 U n e x p o r t i n g d i r e c t o r i e s f o r NFS k e r n e l daemon
. . . done .
11 Removing s f s -c l i e n t . . .
12 Sending s t o p s i g n a l t o SFS C l i e n t s o f t w a r e :
s f s c d .
13 Removing s f s -common . . .
14 S t o p p i n g NFS common u t i l i t i e s : s t a t d .
15 mab : ~ #
Listing 6.6: Usuwanie usługi przez usunięcie pakietu
Oprócz pakietu nfs-common zostały domyślnie usunięte dodatkowe pakiety od niego za-
leżne. W podobny sposób usuwamy zbędne usługi  lpd, smbd, portmap, lwresd, nmbd.
Jeśli chcemy usunąć dane pakiety wraz z plikami konfiguracyjnymi należy dodatowo po-
dać przyremoveargument--purge.
Kolejnym krokiem będzie blokowanie usług bezpośrednio uruchamianych przez pro-
gram inetd. Robimy to poprzez edycję pliku /etc/inetd.conf. Niepotrzebne usługi  ko-
mentujemy , co widać na Listingu 6.7.
1 # d i s c a r d s t r e a m t c p n o w a i t r o o t
i n t e r n a l
2 # d i s c a r d dgram udp w a i t r o o t
i n t e r n a l
3 # d a y t i m e s t r e a m t c p n o w a i t r o o t
i n t e r n a l
4 # t i m e s t r e a m t c p n o w a i t r o o t
i n t e r n a l
5 # t e l n e t s t r e a m t c p n o w a i t t e l n e t d . t e l n e t d
/ u s r / s b i n / t c p d / u s r / s b i n / i n . t e l n e t d
6 f t p s t r e a m t c p n o w a i t r o o t / u s r /
s b i n / t c p d / u s r / s b i n / wu-f t p d - l
7 pop -3 s t r e a m t c p n o w a i t r o o t / u s r /
s b i n / t c p d / u s r / s b i n / i n . qpopper - f / e t c /
qpopper . c o n f
6.2. Usługi systemu operacyjnego podatne na atak 52
8 # imap2 s t r e a m t c p n o w a i t r o o t /
u s r / s b i n / t c p d / u s r / s b i n / imapd
9 # imap3 s t r e a m t c p n o w a i t r o o t /
u s r / s b i n / t c p d / u s r / s b i n / imapd
10 i d e n t s t r e a m t c p wait i d e n t d / u s r /
s b i n / i d e n t d i d e n t d
Listing 6.7: Blokowanie usług w /etc/inetd.conf
Po edycji pliku inetd.conf zalecane jest ponowne uruchomienie usługi poprzez:
mab:~# /etc/init.d/inetd restart
Oczywiście te usługi, które są realizowane przez zewnętrzne programy można także usu-
nąć poprzez odinstalowanie pakietu.
6.2.2 Ataki typu  odmowa usługi
Standardowa instalacja może sprawić, że będą uruchamiane jednocześnie usługi, które
nie są wymagane do poprawnego działania systemu. Przykładowo włamywacz chce za-
blokować jakąś usługę. Tak często się z nią łączy, że nikt poza nim nie będzie w stanie z
niej skorzystać. Usługa będzie niedostępna. Taki atak nazywa się  Denial of service .
Nie ma skutecznej metody zapobiegania tego typu atakom, można je tylko utrudnić,
np. poprzez ustawianie limitów połączeń z jednego adresu. Nie zablokuje to jednak
skutecznie włamywacza, który wykorzystuje sieć rozległą. Tego typu ataki są nazywane
 Distributed Denial of Service .
6.2.3 Ataki typu  przepełnienie bufora
Przepełnienie bufora występuje przy z
le napisanych programach, które w odpowiedni
sposób nie kontrolują danych wprowadzanych przez użytkownika. Na przykład w wyniku
wprowadzania zbyt długiego tekstu (dłuższego niż oczekiwany przez program) może na-
stąpić przepełnienie bufora, zostanie nadpisany stos na którym znajduje się adres pod
który ma zostać wykonany skok po powrocie z danej funkcji. Na taką sytuację czeka
osoba atakująca  może wtedy ustawić adres na tzw. shellcode3, a przez to uzyskać do-
stęp do powłoki i uzyskać uprawnienia określonego użytkownika, który uruchamia dany
program.
3
shellcode  fragment procedury maszynowej, która wywołuje powłokę (shella)
6.3. Zakłócenia pracy sieci 53
W przypadku, gdy następuje przepełnienie bufora w programach setuserid wyko-
rzystywanych przez użytkownika root, osoba atakująca automatycznie może otrzymać
uprawnienia administratora, co dalej może prowadzić do nieobliczalnych szkód w syste-
mie.
Pomimo tego, że jest coraz mniej programów podatnych na przepełnienia bufora, to
ciągle zdarzają się błędy. Co więcej w systemie istnieje wiele miejsc podatnych na ten
atak i na dobrą sprawę każda osoba, która posiada przeglądarkę WWW i zainstalowanego
Linuksa może wykorzystać te luki na przeprowadzenie ataku.
Tego typu ataki dotyczą najczęściej usług: rpc.mountd, rpc.stadt, imapd/popd, wu-
ftpd. Zapobiec temu można poprzez usunięcie usług jeśli nie są one nam potrzebne. Jeśli
są niezbędne dla naszego systemu należy często robić aktualizację programu i poprawek
do aplikacji.
6.3 Zakłócenia pracy sieci
Sieć może nie być tym w rzeczywistości, czym wydaje się być. Osoby atakujące mogą
mieć dostęp do usług i programów o których użytkownik sądzi, że są bezpieczne. Pakiety
ze sfałszowanym z
ródłem mogą oszukiwać reguły zapór ogniowych. I w gruncie rzeczy
użytkownik może sobie kompletnie nie zdawać sprawy z tego, że serwer pocztowy, który
znajduje się w znanym mu pomieszczeniu, w rzeczywistości ma ustawienie ruchu przez
inny serwer na drugim końcu świata. To właśnie są zakłócenia w pracy sieci. Omówię
dwa rodzaje zakłóceń w działaniu sieci: problemy z DNS i trasowaniem.
6.3.1 DNS
DNS to inaczej usługi serwera nazw. W Linuksie rzeczywistym demonem tej usługi
(BIND-a) jest Named. Jego zadaniem jest translacja nazwy na adres IP i odwrotnie.
Usługi te są rozproszonym systemem wykorzystującym pamięć cache, aby zmniejszyć
obciążenie sieci i możliwość powstawania błędów. Serwery nazw przechowują w pa-
mięci wyniki zapytań, przez co nie muszą ponawiać tych samych zapytań.
Problem pojawi się, gdy serwer nie będzie dbał o weryfikację informacji otrzymy-
wanych z innych serwerów (problem pojawił się w wersjach wcześniejszych od 8.1.1).
Taki serwer może zawierać dodatkowe rekordy DNS wraz z żądanymi danymi, np. po-
mocnymi wskazówkami  i wiele serwerów będzie to akceptować na ślepo zapisując w
pamięci. Ten proces nazywa się zatruwaniem pamięci cache BIND.
6.4. Podszywanie się 54
W nowych wersjach BIND-a ten problem został usunięty. Stąd najlepszym sposobem
na uniknięcie tego problemu jest zreinstalowanie BIND-a do nowszej wersji. Dobrym
rozwiązaniem jest też  postawienie dwóch serwerów DNS. Jeden będzie w sieci we-
wnętrznej, drugi poza nią  w zewnętrznej, poza zaporą ogniową. W ten sposób można
umożliwić określonym użytkownikom korzystanie tylko z wewnętrznego serwera, co po-
zwoli w dużej mierze zapobiec zatruwaniu tego serwera DNS.
6.3.2 Trasowanie z użyciem fałszywego z
ródła pakietu
Umożliwia ono dokładne określenie jaką ścieżką pakiet ma poruszać się w Internecie,
by dotrzeć do miejsca przeznaczenia. Takie manipulowanie pakietem pozwala na pozna-
wanie sieci, debugowanie, testowanie bram bezpieczeństwa oraz translatorów adresów 
w efekcie końcowym znacznie ułatwia podszywanie się pod określony adres w sieci.
Sprawdz
my, czy nasz system zezwala na akceptowanie fałszywych z
ródeł w pakie-
tach:
1 mab : ~ # c a t / proc / s y s / n e t / i p v 4 / c o n f / e t h 0 /
a c c e p t _ s o u r c e _ r o u t e
2 1
Mamy włączone takie trasowanie, zatem zezwalamy na podszywanie się pod określony
adres w sieci. Można temu zapobiec zmieniając wartość 1 na 0.
1 mab : ~ # echo 0 > / proc / s y s / n e t / i p v 4 / c o n f / e t h 0 /
a c c e p t _ s o u r c e _ r o u t e
2 mab : ~ # c a t / proc / s y s / n e t / i p v 4 / c o n f / e t h 0 /
a c c e p t _ s o u r c e _ r o u t e
3 0
6.4 Podszywanie się
Pod pojęciem  podszywanie się w potocznym rozumieniu ma się na myśli osobę,
która udaje kogoś kim nie jest. Udaje, że ma uprawnienia jakich w rzeczywistości nie
posiada. Zwykle jest to osoba miła, pełna zaangażowania i chęci niesienia pomocy, ale
jak tylko będzie mieć okazję to wykorzysta wszystkie te  miłe cechy by zdobyć dane,
które są potrzebne. W ten sposób  podszywanie się definiuje nie tylko język potoczny,
ale także inżynieria społeczna.
6.4. Podszywanie się 55
Inżynieria społeczna podaje też dość prostą receptę na to, jak uchronić się przed ata-
kami społecznymi włamywaczy.
Po pierwsze należy być czujnym, należy pytać  niepewną osobę o szczegóły  imię,
nazwisko, nazwisko przełożonego, telefon do przełożonego, a nawet należy zadzwonić
tam, aby się upewnić, że dane, które przekazujemy tej osobie będą bezpieczne.
Tyle o podszywaniu się w aspekcie inżynierii społecznej.
Fachowo podszywanie się nazywa spoofing i jest jednym z podstawowych zagrożeń
dla transmisji w sieci TCP/IP. Jest wiele rodzajów spoofingu, poczynając od MAC, IP,
przez DNS, aż do WWW. Metoda ta polega na podszyciu się pod inny komputer w sieci,
czyli wysłaniu sfałszowanych pakietów do wybranej maszyny, aż do przejęcia całej sesji
użytkownika (connection hijacking). WWW spoofing polega na podmienieniu całego ser-
wera WWW albo takiej zmianie na serwerze WWW, aby każde odwołanie przychodziło
do fałszywego serwera.
6.4.1 Non-blind spoofing
Ten rodzaj ataku ma miejsce, gdy atakujący jest w tej samej podsieci co ofiara. Ata-
kujący widzi pakiety, które pochodzą od komputera, który atakuje (wykorzystuje tu na-
rzędzia do podsłuchiwania, takie jak np. Ethereal. Kiedy atakujący ma już dostęp do
pakietów, włącza się w komunikację pomiędzy komputerami. Atakowany komputer traci
połączenie, tym samym następuje przejęcia połączenia przez atakujący komputer. Takie
przejęcie komputera może spowodować utratę haseł dostępowych (np. w sytuacji gdy
ustawione jest logowanie z tylko określonego hosta, bez hasła dostępu).
6.4.2 Blind spoofing
Ten atak jest trudniejszy, z tego powodu, że atakujący nie ma możliwości obserwo-
wania jakie pakiety są wysyłane przez atakujący komputer. Aby to ominąć, pojedyncze
pakiety są wysyłane do atakowanej maszyny w określonym numerycznie porządku (każdy
pakiet posiada swój numer ISN). Atak tego typu jest dość problematyczny, bo koniecznie
trzeba wiedzieć, co chce się wysłać do atakowanej maszyny, przy czym nie ma bezpo-
średniej weryfikacji, że to co zostało wysłane do atakowanej maszyny zadziałało.
Obecnie protokół TCP zawiera w sobie już zabezpieczenie przed podszywaniem się 
numer ISN jest generowany losowo, co utrudnia stosowanie tego ataku.
6.4. Podszywanie się 56
6.4.3 Man In the Middle Attack
Atak polega na przechwyceniu połączenia pomiędzy dwiema stacjami. Przykładowo,
użytkownik łączy się z tym serwerem i ściąga pocztę. Nie zauważa jednak tego, że w
połączeniu serwer poczty  użytkownik pojawił się nowy punkt  komputer, który prze-
chwycił połączenie. Nowe połączenie w takiej sytuacji wygląda następująco: serwer
poczty  komputer pośredniczący (atakujący)  użytkownik. Zagrożeń jakie niesie ten
rodzaj ataku jest wiele, bo praktycznie wszystko co tylko wychodzi z jednego końca po-
łączenia przechodzi przez komputer pośredniczący.
6.4.4 Fałszowanie adresu MAC
Fałszowanie adresu MAC jest prostą metodą na dostanie się do wnętrza określonej
sieci komputerowej. Zmianę unikalnego adresu MAC można przeprowadzić dosłownie
jednym poleceniem:
mab:~# ip link set eth0 address 00:10:a4:9f:77:bf
Osoba atakująca poprzez sfałszowanie adresu MAC oraz dostanie się przez to w okre-
śloną sieć komputerową może podsłuchiwać i logować wszystkie używane adresy MAC.
Gdy dany adres przez chwilę przestanie nadawać, wtedy haker może podszyć się pod
taką maszynę i oszukać w ten sposób punkt dostępowy (np. serwer DHCP). Fałszowanie
adresu MAC jest praktycznie pierwszym krokiem do tego, by wykorzystywać wcześniej
wymieniane sposoby podszywania się  blind spoofing i man in the middle attack.
Wykrycie, że ktoś się podszywa pod adres MAC jest możliwe, ale tylko wtedy, gdy
określone urządzenie przełączające, np. switch, jest tak skonfigurowane, że dopuszcza
określony adres MAC tylko z jednego portu. I to jest też sposób zapobiegania fałszowania
adresu MAC.
Rozdział 7
Środowisko graficzne
Środowisko graficzne systemu Linux, to najczęstszy sposób  biurkowego wyko-
rzystania Linuksa. Tutaj znajdują się najpopularniejsze aplikacje biurowe (np. Open-
Office.org, StarOffice, KOffice), internetowe, takie jak klienci poczty (np. KMail, Evolu-
tion, Mozilla Mail), przeglądarki WWW (Mozilla, Opera, Galeon, Firebird), komunika-
tory (PSI, GG2, Jabber), oraz wiele innych.
System X Window tworzy okienkowe środowisko graficzne i jest bazą w oparciu o
którą działają menadżery okien, takie jak KDE, GNOME, Window Maker. W zależności
od tego jaki jest używany menadżer okien, taki zwykle używany jest serwer.
Ważne jest, by odpowiednio zabezpieczyć także to środowisko, poza resztą systemu,
szczególnie, że dzięki SSH, można z niego zdalnie korzystać.
Środowisko graficzne zwykle jest uruchamiane za pomocą programów typu XDM (X
Window Display Manager), WDM (WING s Display Manager), GDM (Gnome Display
Manager), KDM (KDE Display Manager). Są one odpowiedzialne za możliwość logo-
wania się do  okienek . Od niego zaczniemy zabezpieczanie środowiska graficznego.
7.1 Bezpieczeństwo WDM
Ponieważ dla mnie najważniejsza jest funkcjonalność i szybkość systemu na którym
pracuję, omówię, według mnie najszybszy menadżer okien Window Maker i odpowiada-
jący mu WDM1. WDM odpowiada za udostępnienie graficznego środowiska. Pozwala
wpisać nazwę użytkownika i hasło, po czym uruchamia serwer X. W takim przypadku,
użytkownik od razu uruchamia środowisko graficzne, pomijając logowanie do terminala
i ręczne uruchamianie serwera X poprzez polecenie startx.
1
WING s Display Manager
7.1. Bezpieczeństwo WDM 58
Standardowa konfiguracja WDM znajduje się w katalogu /etc/X11/wdm/2. Najważ-
niejsze pliki konfiguracyjne to:
1. wdm-config  plik kontrolujący z
ródła określonych zachowań WDM;
2. wdm.options  tutaj ustawiane są flagi, które determinują zachowanie WDM;
3. Xacces  plik kontroli dostępu dla połączeń z WDM.
Domyślnie konfiguracja WDM pozwala na logowanie się do środowiska graficznego
tylko jako root. Wcześniej wspominałam już, że praca z konta administratora jest bardzo
niebezpieczna, dlatego też dobrze by było, gdyby ze środowiska graficznego mógł też
korzystać zwykły użytkownik. Dlatego w pliku wdm-config linię, w której znajduje się
wpis:
DisplayManager*wdmRoot: true
zmieniamy na:
DisplayManager*wdmRoot: false
Od teraz lokalnie korzystać ze środowiska graficznego może także zwykły użytkow-
nik.
Należy zaznaczyć, że w KDE i GNOME powyższa sytuacja nie ma miejsca. W kon-
figuracjach tych menadżerów określa się, czy root może logować się w środowisku gra-
ficznym. Oczywiście nie jest zalecana taka możliwość, stąd w odpowiednim pliku konfi-
guracyjnym należy odnalez
ć linię:
AllowRoot=true
i  true zamienić na  false . Od tego momentu logowanie do środowiska graficznego
jako root będzie niemożliwe.
Aby można było korzystać z tego środowiska tylko i wyłącznie lokalnie (z różnych
względów polityka bezpieczeństwa może nie pozwalać na zdalne uruchamianie mena-
dżera okien  np. ze względu na możliwość podsłuchiwania klawiatury) należy w pliku
wdm-config dopisać linię:
DisplayManager.RequestPort: 0
2
Analogicznie w katalogu /etc/X11 znajdą się katalogi z plikami konfiguracyjnymi dla XDM i TWM.
Natomiast odpowiednie katalogi dla menadżerów KDE i GNOME znajdują się odpowiednio w /etc/kdm/ i
/etc/gdm/
7.2. Serwery X11 59
oraz w pliku Xacces zakomentować linię:
* #any host can get a login window
Oczywiście, dla określonych hostów można zrobić wyjątek i udostępniać zdalne lo-
gowanie. To jednak należy wykonać już bezpośrednio na firewallu. Zamiast w plikach
konfiguracyjnych WDM ustawiać blokowanie logowania dopisujemy do firewalla odpo-
wiednie reguły (Listing 7.1).
1 / s b i n / i p t a b l e s -A INPUT -p udp - s 1 9 2. 1 6 8 . 2 2 2 . 1 7 - -
d p o r t 177 - j ACCEPT
2 / s b i n / i p t a b l e s -A INPUT -p t c p - s 1 9 2. 1 6 8 . 2 2 2 . 1 7 - -
d p o r t 177 - j ACCEPT
3 / s b i n / i p t a b l e s -A INPUT -p udp -- d p o r t 177 - j DROP
4 / s b i n / i p t a b l e s -A INPUT -p t c p -- d p o r t 177 - j DROP
Listing 7.1: Reguły iptables kontrolujące dostęp do WDM
Pierwsze dwie linie przedstawiają reguły, które umożliwiają dostęp ze ściśle określo-
nego hosta 192.168.222.17, dla pakietów tcp i udp. W ten sposób otwieramy port 177,
na którym nasłuchuje WDM. Dwie ostatnie linie, to blokowanie dostępu dla wszystkich
pozostałych hostów.
Dzięki takiemu postępowaniu minimalizujemy ilość ataków bezpośrednio na WDM.
7.2 Serwery X11
Serwer X nasłuchuje na 64 portach (6000  6063), i w ten sposób jednocześnie może
być uruchomionych maksymalnie 64 połączeń z serwerem X. Zwykle jednak nie jest
wykorzystywanych więcej jak 2  3 połączenia, a pozostałe porty nie są wykorzystywane.
Problemem w tej sytuacji są otwarte porty. Protokół X, który pozwala na przekazywa-
nie poleceń, daje pełny dostęp do serwera  program może nie tylko wyświetlać okienko
na pulpicie, ale także przeprowadzać działania szkodzące bezpieczeństwu.
Przykładowo, mogą być rejestrowane wszystkie wciskane klawisze, co w konsekwen-
cji może spowodować, że będą uruchamiane dodatkowe okna służące do ataków, mogą
być zamykane okna (jako pewien rodzaj ataków typu DoS).
Aby zabezpieczyć taki serwer stosuje się metody polegające na: wyłączeniu dostępu
do sieci na poziomie menadżera okien, blokowanie dostępu na poziomie jądra systemu
oraz blokowanie za pośrednictwem xhost.
7.2. Serwery X11 60
7.2.1 Wyłączenie dostępu z sieci na poziomie WDM
Najprostszą metodą zabezpieczenia jest sprawienie, by serwer X nie nasłuchiwał sieci.
Nie ma najmniejszego powodu, by serwer X nasłuchiwał na portach. Do połączenia (cią-
gle pracując już na serwerze X) z innym komputerem przez SSH wykorzystuje się wbudo-
wane przekazywanie, które jest zakodowane. W związku z czym, aplikacje X nie muszą
się łączyć bezpośrednio z portami X-ów komputera.
Samo wyłączenie nasłuchiwania można wykonać na dwa sposoby. Albo tylko na
poziomie konkretnego użytkownika, i wtedy należy dodać odpowiedni alias do jego pliku
<"/.profile:
alias startx= startx - --nolisten tcp
albo globalnie, i w takim przypadku administrator powinien stworzyć odpowiedni skrypt,
np. taki jak na Listingu 7.2
1 # ! b i n / sh
2 exec X - n o l i s t e n t c p "$@"
Listing 7.2: Skrypt blokujący nasłuchiwanie serwera X
Aby plik był stosowany w stosunku do wszystkich użytkowników, należy nazwać go xser-
verrc, przekopiować do katalogu /etc/X11/xinit/, oraz ustawić mu prawa wykonywania
(Listing 7.3).
1 mab : ~ # mv s k r y p t 1 x s e r v e r e r
2 mab : ~ # cp x s e r v e r r c / e t c / X11 / x i n i t /
3 mab : ~ # chmod 7 5 5 / e t c / X11 / x i n i t / x s e r v e r r c
Listing 7.3: Uruchamianie globalnego blokowania nasłuchiwania serwera X
Jeśli serwer X jest uruchamiany z poziomu WDM, dobrze jest dokonać drobnych zmian w
pliku /etc/X11/wdm/Xservers. Należy dodać wpis   nolisten tcp do wszystkich wpisów
w tym pliku (Listing 7.4).
1 # / e t c / X11 / wdm / X s e r v e r s
2 #
3 : 0 l o c a l / u s r / b i n / X11 /X - n o l i s t e n t c p
Listing 7.4: Zmiany w pliku Xservers
7.2. Serwery X11 61
7.2.2 Wyłączenie dostępu z sieci na poziomie jądra
Jeśli jednak blokowanie polegające na wyłączeniu dostępu sieciowego jest niewska-
zane (np. kilku użytkowników musi korzystać ze zdalnego uruchamiania serwera X),
blokowanie można przeprowadzić w sposób selektywny na poziomie jądra. Polega to
na dopisaniu odpowiednich reguł do iptables. Dzięki temu, będzie możliwe nawiązanie
połączenia z określonego hosta, przy jednoczesnym blokowaniu pozostałych.
Przykładowe reguły są pokazane na Listingu 7.5.
1 / s b i n / i p t a b l e s -A INPUT -p t c p - s 1 9 2. 1 6 8 . 2 2 2 . 1 7 - -
d p o r t 6000:6063 - j ACCEPT
2 / s b i n / i p t a b l e s -A INPUT -p t c p -- d p o r t 60 00:6063 - j
DROP
Listing 7.5: Reguły iptables selektywnie blokujące połączenia
Pierwsza linie określa połączenia z określonym hostem, które nie są odrzucane. Druga
linia powoduje odrzucenie wszystkich połączeń z innymi niż pierwszy hostami.
7.2.3 Blokowanie na poziomie Xhost
Jeśli z jakichś powodów dwie wcześniejsze metody blokowania nie mogą być zreali-
zowane, pozostaje jeszcze możliwość blokowanie na poziomie Xhost. Nie jest to jednak
najlepsze rozwiązanie, poprzez dodanie do zaufanego hosta spowodujemy, że każdy użyt-
kownik danego hosta będzie mógł połączyć się z naszym komputerem.
Dodawanie określonego hosta do xhost jest możliwe tylko z poziomu użytkownika
który uruchomił serwer X. Cała procedura przedstawiona jest na Listingu 7.6
1 iza@mab : ~ $ x h o s t
2 a c c e s s c o n t r o l e n a b l e d , o n l y a u t h o r i z e d c l i e n t s can
c o n n e c t
3 iza@mab : ~ $ x h o s t + 1 9 2 . 1 6 8 . 2 2 2 . 1 7
4 1 9 2 . 1 6 8 . 2 2 2 . 1 7 b e i n g added t o a c c e s s c o n t r o l l i s t
5 iza@mab : ~ $ x h o s t
6 a c c e s s c o n t r o l e n a b l e d , o n l y a u t h o r i z e d c l i e n t s can
c o n n e c t
7 INET : 1 9 2 . 1 6 8 . 2 2 2 . 1 7
Listing 7.6: Procedura dodawania zaufanego hosta do xhost
7.3. Serwer X i SSH 62
Przy takim sposobie zabezpieczania można dodatkowo włączyć uwierzytelnianie X.
Zarządza nim xauth. W Debianie, domyślnie jest przekazywany do serwera X, podczas
jego uruchamiania, argument -auth.
Serwer X nie pozwoli na na połączenie klienta, jeśli ten nie będzie posiadać akcepto-
walnego  cookies .
Jakie  cookies są akceptowane przez nasz komputer można zobaczyć, wydając pole-
cenie xauth list. Jego wynik obrazuje Listing 7.7
1 1 9 2 . 1 6 8 . 2 2 2 . 1 9 : 0 MIT-MAGIC-COOKIE-1
300520116846423970507 d585c462c33
2 mab / u n i x : 0 MIT-MAGIC-COOKIE-1
300520116846423970507 d585c462c33
3 mab / u n i x : 1 0 MIT-MAGIC-COOKIE-1 6
dc3876b9e1fa0724d77713112bdc6ee
Listing 7.7: Akceptowane przez przykładowy system  cookies
Pierwsze pole to informacja o serwerze, którego  cookie jest akceptowane, ostatnia war-
tość to samo  cookie .
Kolejne wpisy dodawane są automatycznie podczas logowania się z kolejnych ma-
szyn.
7.3 Serwer X i SSH
W rozdziale 4.3.1 wspomniałam, że możliwość zdalnego uruchamiania serwera X
przez SSH jest możliwa po odpowiednim przekonfigurowaniu pliku /etc/ssh/sshd_config.
Z serwerem X, stosując SSH, łączymy za pomącą polecenia:
iza@nb~:$ ssh -X iza@192.168.222.19
1 iza@mab : ~ $ x a u t h l i s t
2 mab / u n i x : 1 0 MIT-MAGIC-COOKIE-1 3407100
f 6 8 7 4 3 5 4 9 2 1 8 0 2 9 9 f 0 6d b f 7 0 f
3 iza@mab : ~ $
Listing 7.8: Nowe  cookie
Przykładowo mamy użytkownika iza, który z lokalnego komputera nb łączy się, przy
użyciu SSH, z maszyną mab. Przekazywanie będzie w takim przypadku wyglądało na-
stępująco:
7.3. Serwer X i SSH 63
1. SSH z komputera nb łączy się z komputerem mab i skutecznie się uwierzytelnia.
2. SSHD z komputera mab wiąże się z lokalnym portem serwera X (zazwyczaj jest
to 6010, ale jest to w pełni konfigurowalne w SSH w pliku /etc/ssh/sshd_config, za
pomocą zmiennejX11DisplayOffset).
3. SSHD z komputera mab tworzy nowe  cookie xauth dla użytkownika (Listing
7.8).
4. SSHD z komputera mab ustawia zmienną $DISPLAY na lokalnie związany pseudo-
serwer X.
5. SSHD uruchamia powłokę użytkownika i rozpoczyna się interaktywna sesja (Li-
sting 7.9).
1 mab : ~ $ echo $DISPLAY
2 l o c a l h o s t : 1 0 . 0
Listing 7.9: Interaktywna sesja
Za każdym razem, gdy uruchamiana jest aplikacja klienta X, łączy się ona z $DISPLAY i
udostępnia  cookie dostępne w pliku <"/.Xauthority. Serwer, który akceptuje to połącze-
nie jest tylko lokalnym procesem SSHD na komputerze mab. Prawidłowość  cookie jest
potwierdzana na komputerze nb, po czym sesja X jest odsyłana, przez zakodowany kanał,
do serwera X11 na komputerze nb. Dla komputera nb połączenie wydaje się pochodzić z
lokalnego hosta, a nie od zdalnego komputera mab. Jak widać nie jest konieczne, by listy
kontroli xhost zezwalały na połączenia ze zdalnym komputerem.
Można powiedzieć, że pod kątem bezpieczeństwa, takiemu systemowi nie brakuje.
Problem pojawia się jednak, gdy zauważymy, że  cookie są przechowywane w pliku
<"/.Xauthority, który praktycznie nie jest zabezpieczony. Każdy, kto może odczytać ten
plik, tym samym może połączyć się z danym serwerem X11.
Aby do takiej sytuacji nie dopuścić, należy ustawić odpowiednie prawa dostępu do
pliku:
iza@mab:~$ chmod 600 ~/.Xauthority
Należy jednak pamiętać o tym, że superużytkownik systemu będzie miał dostęp do tego
pliku, bez względu na to, jakie plik będzie miał nadane uprawnienia.
7.4. Podsumowanie 64
7.4 Podsumowanie
Po przejściu przez wszystkie metody zabezpieczania X Window dochodzi się do
wniosku, że tak naprawdę nie ma możliwości tego w 100% zabezpieczyć. Na ten stan
ma wpływ budowa X Window. Oparta jest ona na architekturze klient  serwer. X Server
jest programem, który działa na maszynie użytkownika. Akceptuje połączenia z róż-
nych maszyn, wyświetlając okienka. Po sieci przekazywane są informacje o kliknięciu
myszką, zdarzeniach klawiatury  od X Serwera do X Klienta. X Klient to program na-
pisany dla X. Wysyła on do X Serwera polecenia narysowania okienka, itd. X Serwer i X
Klient mogą oczywiście być na różnych maszynach. Niestety kanał X Serwer  X Klient
nie jest kodowany, i nie przewiduje tego standard X. Zapewne jeszcze długo nie będzie
przewidywał. Można temu zaradzić jedynie stosując przekazywanie przez SSH.
Rozdział 8
Poczta elektroniczna
Usługa poczty elektronicznej to proces dzielący się na kilka etapów. Pierwszy z nich,
to wykorzystywany bezpośrednio przez użytkowników program do obsługi poczty, tzw.
agent MUA1. Najpopularniejsze MUA w Linuksie to Pine, Mutt, Elm, Kmail, Evolution,
oraz wiele, wiele innych.
Drugi etap to agent przesyłania poczty  MTA2. Jego zadaniem jest przekazywanie
poczty pomiędzy komputerami. Najpopularniejsze MTA to Sendmail, Qmail, Postfix,
Exim.
Trzeci etap to agent dostarczania poczty  MDA3, którego zadaniem jest odbieranie
poczty z MTA i przekazywanie jej do skrzynki MUA i odwrotnie. Najpopularniejszy
MDA to Procmail.
Ostatni, czwarty etap jest opcjonalny  to agent dostępu, taki jak Fetchmail. Jego
zadaniem jest łączenie MUA z miejscem przechowywania tej poczty.
Na każdym z etapów można w jakiś sposób zabezpieczyć pocztę. Na pierwszym
poprzez wybór stabilnego programu do obsługi poczty i odpowiednią konfigurację. Na
drugim wybranie odpowiedniego MTA oraz bezpieczne skonfigurowanie go. Trzeci i
czwarty etap to odpowiednia konfiguracja.
Dodatkowym można zabezpieczyć pocztę przed spamem oraz wirusami. W tym roz-
dziale skupię się MTA, ponieważ tak naprawdę jeśli on będzie dobrze skonfigurowany i
bezpieczny, to cały proces przesyłania poczty będzie stosunkowo bezpieczny.
1
Mail User Agent
2
Mail Transport Agent
3
Mail Delivery Agent
8.1. Wybór programów 66
8.1 Wybór programów
Wybór odpowiednich programów do obsługi poczty elektronicznej to połowa sukcesu
w uzyskaniu bezpiecznej poczty. Dobry agent transportu będzie szybki, mało podatny na
ataki, będzie zawierał relatywnie mało błędów i dziur w kodzie, będzie łatwo konfiguro-
walny i będzie dobrze współpracował z innymi aplikacjami, np. z filtrem antyspamowym
albo z programem antywirusowym.
Przykładem takiego MTA będzie Postfix. Jest to program szybki, prosty w konfigu-
racji i doskonale współpracuje z dodatkowymi aplikacjami takimi jak np. MKSvir czy
Amavis. Dodatkowym jego atutem będzie to, że w przeciwieństwie do popularnego Send-
maila nie posiada znanych dziur w kodzie, które mogłyby stanowić  boczną furtkę .
Jako program antywirusowy proponuję program MKSvir. Jest to jeden z najlepiej na-
pisanych programów antywirusowych pod Linuksa. Pomimo tego, że program w chwili
obecnej ma status beta jest to doskonały program do skanowania poczty pod kątem wiru-
sów.
Linux jako taki nie jest podatny na wirusy. Jest to związane z tym, że Linux ma ja-
sno sprecyzowane definicje użytkowników, grup, własności plików oraz uprawnień. Stąd
dany wirus może zaszkodzić co najwyżej użytkownikowi, który uruchomił dany program,
w przeciwieństwie do systemu MS Windows, gdzie uruchomienie wirusa może spowo-
dować całkowity paraliż. Skąd więc pomysł na program antywirusowy dla Linuksa?
Serwer poczty może być tak skonfigurowany, że będzie możliwe ściąganie poczty po-
przez programy MUA dostępne na MS Windows, np. poprzez Outlook Express. Skano-
wanie poczty już na serwerze pod kątem wirusów będzie minimalizowało ilość wirusów
w sieci.
Bardzo uciążliwe i dość niebezpieczne jest tzw. spamowanie. Spam to elektroniczne
wiadomości wysyłane celowo, w dużych ilościach do osób, które wcale tego nie chcą.
Jego istotą jest rozsyłanie dużej liczby wiadomości o jednakowej treści do nieznanych
sobie osób. Nie ma znaczenia jaka jest treść tych wiadomości.
Spam dzieli się na UCE4, czyli spam komercyjny o charakterze reklamowym, oraz
UBE5, czyli niechciane maile o charakterze niekomercyjnym takie jak  łańcuszki szczę-
ścia , masowe rozsyłanie ostrzeżeń o wirusach, czy masowe rozsyłanie próśb o pomoc.
Spam jest niebezpieczny z kilku powodów: po pierwsze powoduje zatykanie się łącz
i blokuje miejsce na twardych dyskach, po drugie jego przetworzenie zabiera czas ser-
4
Unsolicited Commercial Email
5
Unsolicited Bulk Email
8.2. Konfiguracja Postfix a 67
werom spowalniając ich działanie oraz po trzecie powoduje stratę czasu poszczególnych
użytkowników, bo muszą oni czytać i kasować niepotrzebne wiadomości.
8.2 Konfiguracja Postfix a
Pliki konfiguracyjne serwera znajdują się w katalogu /etc/postfix/. Najważniejszy z
nich to /etc/postfix/main.cf, a jego standardowa zawartość pokazana jest na Listingu 8.1.
Komendy są dość jasne, więc nie powinny nikomu sprawić trudności w odpowiedniej
konfiguracji, przynajmniej tej podstawowej.
1 comm a n d _ di re ctory = / u s r / s b i n
2 d a e m o n _ d i r e c t o r y = / u s r / l i b / p o s t f i x
3 p r o g r a m _ d i r e c t o r y = / u s r / l i b / p o s t f i x
4 smtpd _banne r = $myhostname ESMTP $mail_name (
Debian /GNU)
5 s e t g i d _ g r o u p = p o s t d r o p
6 b i f f = no
7 append_dot_mydomain = no
8 myhostname = mab
9 a l i a s _ m a p s = hash : / e t c / a l i a s e s
10 a l i a s _ d a t a b a s e = hash : / e t c / a l i a s e s
11 m y o r i g i n = / e t c / mailname
12 m y d e s t i n a t i o n = mab , l o c a l h o s t . l o c a l d o m a i n , ,
l o c a l h o s t
13 r e l a y h o s t =
14 mynetworks = 1 2 7 . 0 . 0 . 0 / 8
15 mailbox_command = p r o c m a i l - a "$EXTENSION"
16 m a i l b o x _ s i z e _ l i m i t = 2 0 0 0 0 0 0 0
17 r e c i p i e n t _ d e l i m i t e r = +
Listing 8.1: Standardowa zawartość pliku /etc/postfix/main.cf
Nas interesują możliwości ustawiania różnego rodzaju ograniczeń, które będą powodo-
wały, że system będzie bezpieczniejszy.
8.2. Konfiguracja Postfix a 68
8.2.1 Ograniczenie zasobów
Postfix posiada bardzo duży zakres możliwości jeśli chodzi o wprowadzanie ograni-
czeń, dzięki którym staje się odporny na różnego rodzaju bomby mailowe i ataki DoS.
Pierwszym krokiem będzie ograniczenie całkowitej ilości procesów Postfix a, które w
danym momencie mogą być uruchomione.
Robimy to ustawiając zmienną default_proces_limit w pliku main.cf. Standardowo
jest ona ustawiona na 50. Jest to odpowiednia ilość dla większości systemów. Można
to jednak sprecyzować, stosując tzw.  usługa za usługę , czyli dokładne sprecyzowanie
jaka jest maksymalna ilość działających konkretnych procesów, np. SMTP. Robimy to
poprzez wpisanie w pliku /etc/postfix/master.cf, w kolumnie maxproc liczbę procesów
jaką gwarantujemy danej usłudze.
Dobrym rozwiązaniem jest określenie sensownej wielkości skrzynki pocztowej. Zbyt
duża skrzynka przy zbyt dużej ilości użytkowników i niezbyt dużym dysku może spo-
wodować zapchanie dysku. Stąd przydatne jest ustawienie zmiennej: mailbox_size_limit.
Tutaj uwaga  rozmiar podawany jest w bajtach, np. 51200000 (50 MB).
Zdarza się, że użytkownicy wysyłają ten sam list do wielu użytkowników. To także
można dookreślić. Użytkownicy, którzy wysyłają jeden list do więcej niż ok. 50 odbior-
ców, mogą być traktowani jako spamerzy, a z tym należy walczyć. Zatem ustawiamy
smtpd_recipient_limit = 50.
Zdarza się, że system zaczyna dziwnie się zachowywać. Może to być spowodowane
brakiem miejsca na dysku  którejś z używanych przez system partycji. Takim miej-
scem podatnym na przepełnienie jest np. /var/spool/, gdzie z reguły jest przechowywana
nowa poczta. Aby uniemożliwić Postfix owi zapełnienie tej partycji, można zdefiniować
ilość wolnego miejsca na dysku, którego nie może przekroczyć. Innymi słowy, dopóki
miejsca jest więcej niż queue_minfree Postfix będzie dostarczał pocztę. Jeśli tego miej-
sca jest mniej  odmawia przyjęcia nowej poczty dla użytkownika oraz informuje o tym
odpowiednią osobę (domyślnie informuje o tym administratora).
Domyślnie ta opcja ta jest wyłączona, co oznacza, że Postfix może zapełnić nową
pocztą całą partycję. Aby tego uniknąć i zostawić np. minimalnie ok. 10 MB wolnego
miejsca należy ustawić zmienną queue_minfree = 10000000.
8.2.2 Ograniczenia listów przychodzących i wychodzących
Możliwe jest wysyłanie anonimowych listów przez określony serwer. Stosuje się do
tego bezpośrednie połączenie na port 25 albo używa odpowiedniego programu by to wy-
8.2. Konfiguracja Postfix a 69
konał. Nie zabezpieczenie tej  furtki może spowodować, że ktoś z zewnątrz będzie
wysyłał spam, np. maile z pogróżkami, przez nasz serwer z dowolnym adresem nadawcy.
Odpowiedzialność prawna spadnie na administratora serwera. Można się przed tym za-
bezpieczyć ustawiając trojakie ograniczenia  na podstawie adresu IP komputera łączą-
cego się z serwerem, na podstawie adresu nadawcy i na podstawie adresu odbiorcy. W
pierwszym wypadku można wprowadzić ograniczenia:
" permit_mynetworks, które pozwala na połączenie się z naszym serwerem kompute-
rom z naszej sieci lokalnej, a dokładnie tym komputerom, które pasują do zmiennej
określonej w $mynetworks; np.:
smtpd_client_restrictions = permit_mynetworks, reject, będzie pozwalało na wysy-
łanie listów tylko komputerom z naszej sieci lokalnej.
Jest to doskonałe rozwiązanie dla sieci lokalnej, ale tylko w przypadku, gdy wiemy
na pewno, że tylko z niej będą wysyłane listy.
" reject_unknown_client, które odrzuca komputer, którego adres IP nie ma wpisu w
DNS; np.:
smtpd_client_restrictions = reject_unknown_client, permit, będzie pozwalało wy-
syłać wszystkim tym, którzy mają wpis w DNSie.
Aby wysyłał listy z sieci lokalnej, przed reject_unknown_client należy wpisać per-
mit_mynetworks.
W drugim przypadku, gdy ograniczenie jest określane na podstawie adresu nadawcy,
w ogóle nie jest brany pod uwagę adres IP komputera łączącego się z serwerem, ale
sprawdzane jest pole from:. Odpowiada za to zmienna smtpd_sender_restrictions. W tym
przypadku możliwe są ograniczenia:
" reject_unknown_sender_domain, które odrzuca list, jeśli adres nadawcy, a dokład-
nie część po @ adresu nadawcy, nie ma wpisu w DNS.
" reject_non_fqdn_hostname, które odrzuca list, jeśli adres nadawcy, dokładnie część
po @ adresu nadawcy nie jest  pełna .
I tak przykładowo: smtpd_sender_restrictions = reject_unknown_sender_domain, re-
ject_non_fqdn_hostname odrzuci nonsensowne i głupie adresy nadawcy łącznie z jego
listami.
Trzeci przypadek to ograniczanie na podstawie listu odbiorcy, adresu docelowego.
Odpowiada za to zmienna smtpd_recipient_restrictions. Możliwe są ograniczenia:
8.2. Konfiguracja Postfix a 70
" reject_non_fqdn_recipient, które ma odrzucić list, jeśli podany adres odbiorcy nie
jest  pełny .
" reject_unknown_recipient_domain, które ma odrzucić list, jeśli adres docelowy li-
stu nie istnieje w DNS.
" permit_auth_destination, które przyjmuje list, jeśli to nasz serwer jest jego celem
lub adres przeznaczenia zawiera się w zmiennej $relay_domains. Jeśli warunek nie
jest spełniony, bierze pod uwagę kolejne ograniczenia.
" reject_unauth_destination, które odrzuca list, jeśli to nasz serwer nie jest jego prze-
znaczeniem, przy czym nie sprawdza innych ograniczeń.
" check_relay_domains, które przyjmuje list jeśli adres IP komputera, który wysyła
list pasuje do $relay_domains, albo celem listu jest $relay_domains lub to nasz
serwer jest komputerem docelowym, w przeciwnym wypadku odrzuca go.
I przykładowo:
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
to wartość domyślna ograniczenia.
Ale już:
smtpd_recipient_restrictions = reject_unknown_recipient_domain,
reject_non_fqdn_recipient
nie pozwoli na wysłanie listu do nieistniejących komputerów docelowych.
8.2.3 Postfix + SASL
SASL6, to pakiet opracowany na Carnegie Mellon University. Przeprowadza on uwie-
rzytelnianie wykorzystując swoją bazę danych lub mechanizm PAM.
Ten pakiet jest o tyle interesujący, że powoduje możliwość uwierzytelnienia wysyła-
nej przez serwer poczty. Ma to na celu zabezpieczenie przed wysyłaniem poczty przez
nieuprawnionych użytkowników.
Pakiet SASL znajdziemy w innej paczce  Cyrus, który łatwo można zintegrować z
wieloma MTA, w tym Postfix em. Instalujemy pakiet poleceniem:
mab:~# apt-get install cyrus*
6
Simple Authentication and Security Layer
8.2. Konfiguracja Postfix a 71
Po zainstalowaniu, katalogu programu Cyrus  /var/lib/cyrus tworzymy plik smtpd.conf.
Następnie wpisujemy do niego linię określającą w jaki sposób SASL będzie korzystał z
bazy haseł.
Możliwości są dwie: albo będzie miał własną bazę, albo wykorzysta plik /etc/shadow.
W pierwszym przypadku użytkownik będzie posiadał 2 hasła  jedno do konta shell, dru-
gie do poczty, co z pewnością będzie zapobiegało przechwyceniu hasła do shella, ale
będzie musiał zapamiętać dwa hasła, co dla wielu użytkowników bywa zadaniem ponad
ich możliwości i będzie stanowić dla systemu większe zagrożenie niż ewentualność prze-
chwycenia przez sieć hasła do shella. W przypadku drugim, będzie jedno hasło i dla
shella i dla poczty i tu przechwycenie hasła do skrzynki pocztowej będzie jednoznaczne
ze zdobyciem hasła do shella.
Samemu należy zdecydować którą opcję zastosować. Osobiście uważam, że można
zaryzykować używanie jednego hasła. Stąd w pliku /etc/smtpd.conf wpiszemy:
pwcheck_metchod: pwcheck
Teraz trzeba zmienić trochę konfigurację Postfix a. W pliku /etc/postfix/main.cf wpi-
sujemy zawartość Listingu 8.2
1 s m t p d _ s a s l _ a u t h _ e n a b l e = yes
2 b r o k e n _ s a s l _ a u t h _ c l i e n t s = yes
3 s m t p d _ s a s l _ s e c u r i t y _ o p t i o n s = noanonymous
4 s m t p d _ r e c i p i e n t _ r e s t r i c t i o n s =
pe rmi t_my_netwo r ks ,
p e r m i t _ s a s l _ a u t h e n t i c a t e d ,
c h e c k _ r e l a y _ d o m a i n s
Listing 8.2: Konfiguracja SASL dla Postfix a
Linia pierwsza włącza uwierzytelnianie. Dzięki drugiej możliwe jest uwierzytelnianie
starszych programów pocztowych, np. MS Outlook Express 4.x. Trzecia linia zapobiega
logowaniu się na serwer jako anonymous. Ostatnia linia zmusza do zalogowania się i
uwierzytelnienia każdemu, kto chce wysłać przez serwer pocztę.
Niestety to nie wystarczy, by całkowicie zabezpieczyć się przed niepowołanym wy-
syłaniem poczty z serwera. Konieczne jest jeszcze dopisanie do pliku /etc/postfix/main.cf
linii zawartych w Listingu 8.3.
1 smtpd \ _ s e n d e r \ _ l o g i n \ _maps = hash : / e t c / p o s t f i x /
l o g i n \ _maps
8.3. MKSvir i Amavis 72
2 smtpd \ _ s e n d e r \ _ r e s t r i c t i o n s = r e j e c t \ _ s e n d e r \
_ l o g i n \ _mismatch
Listing 8.3: Dodatkowa konfiguracja main.cf
Następnie tworzymy plik login_maps i wpisujemy doń adres pocztowy i login ssl, np.:
[e-mail] iza. Teraz po autoryzacji jako iza, możliwe będzie wysłanie wiadomości z
adresem zwrotnym tylko [e-mail]. Następnie trzeba wydać polecenie:
mab:~# postmap /etc/postfix/login_maps
oraz przeładować samego Postfix a.
W Debianie Postfix jest chrootowany, zatem, aby powyższe działało konieczna jest
drobna zmiana w pliku /etc/postfix/master.cf. W linii pierwszej (smtp) w kolumnie chroot
należy zamiast znaku    wpisać literkę  n .
8.3 MKSvir i Amavis
MKSvir to bardzo popularny polski program antywirusowy. Wersja dla Linuksa poja-
wiła się dość póz
no, ale już była w pełni działającym skanerem.
Jak piszą autorzy w dokumentacji,  mks_vir dla systemów Linux [...] na platformie
Intela x86 powstał z potrzeby ograniczenia rozprzestrzeniania się wirusów korzystających
z e-mail i jako drogi rozprzestrzeniania się. Z tego też powodu zaczęli udostępniać na
swoich stronach7 bezpłatną wersję dla tego systemu. Wersja programu ma obecnie status
beta, co wiąże się z tym, że konieczne jest rozbudowanie programu o dodanie różnych
reakcji po znalezieniu wirusa w pliku lub e-mailu, na przykład: pierwsza akcja: wylecz,
druga: zmień nazwę, trzecia: skasuj. Tym niemniej już na dzień dzisiejszy program
spełnia swoje zadanie  zabezpiecza przed wirusami przesyłanymi drogą  mailową .
Najbardziej aktualną wersję programu, wraz z najnowszymi bibliotekami wirusów
można znalez
ć na stronie domowej programu. Zatem pobieramy program, demona i bazy,
tak jak na Listingu 8.4.
1 mab : ~ # wget h t t p : / / download . mks . com . p l / download
/ l i n u x / mks32-1-9-5-Linux-i 3 8 6 . t g z
2 mab : ~ # wget h t t p : / / download . mks . com . p l / download
/ l i n u x / mksdLinux - 1 . 1 5 . 2 . t g z
7
http://www.mks.com.pl/
8.3. MKSvir i Amavis 73
3 mab : ~ # wget h t t p : / / download . mks . com . p l / download
/ l i n u x / bazy4 . t g z
Listing 8.4: Pobieranie antywirusa MKSvir
Następnie instalujemy program w systemie, tak jak pokazane jest na Listingu 8.5
1 mab : ~ # t a r - z x f mks32-1-9-5-Linux-i 3 8 6 . t g z
2 mab : ~ # cp mks32-1-9-5-Linux-i 3 8 6 / mks32 . s t a t i c /
u s r / b i n / mks32
3 mab : ~ # chmod 7 5 5 / u s r / l o c a l / b i n / mks32
4 mab : ~ # chown r o o t : r o o t / u s r / l o c a l / b i n / mks32
5 mab : ~ # mkdir / var / l i b / mks32 /
6 mab : ~ # t a r - z x f bazy4 . t g z -C / var / l i b / mks32 /
7 mab : ~ # echo --mks-v i r -dat -p a t h =/ var / l i b / mks32 /
bazy4 / > > / e t c / m k s _ v i r . c f g
8 mab : ~ # chmod 444 -R / var / l i b / mks32 / bazy4 /
Listing 8.5: Instalacja antywirusa MKSvir
Przeprowadzamy test, czy wszystko działa. Pobieramy z Internetu przykładowy wi-
rus8, a następnie wydajemy polecenie:
mab:~# mks32 eicar.com
Powinniśmy otrzymać wynik skanowania pokazany na Listingu 8.6
1 mks_vir : i n i t . . . 1 . 9 . 5 f o r Linux i386
, 2 0 0 3 . 1 2 . 1 9
2 mks_vir : d a t a b a s e v e r s i o n 2 0 0 4 1 2 9 3 4
3 mks_vir : i n i t OK, s c a n mode
4 mks_vir : check f i l e ( s )
5 mks_vir : f i l e : e i c a r . com
6 mks_vir : -- h e u r i s t i c f o r v i r u s E i c a r . T e s t
7 mks_vir : -- h e u r i s t i c f o r v i r u s E i c a r . T e s t
8 mks_vir : s t a t u s : v i r u s found : e i c a r . com
9 mks_vir : e x i t code : 0 x01
Listing 8.6: Wynik testowego skanowania antywirusem
8
http://www.eicar.com/download/eicar.com
8.3. MKSvir i Amavis 74
Pracę antywirusa można przyspieszyć wykorzystując demona MKS-a. Proces instala-
cji pokazany jest na Listingu 8.7
1 # i n s t a l a c j a demona
2 mab : ~ # t a r - z x v f mksdLinux - 1 . 1 5 . 2 . t g z
3 mab : ~ # cd mksd - 1 . 1 5 . 2 /
4 mab : ~ # cp mksd / u s r / s b i n
5 mab : ~ # cp mksscan / u s r / b i n
6 mab : ~ # chown r o o t : r o o t / u s r / s b i n / mksd / u s r / b i n /
mksscan
7 mab : ~ # chmod 7 0 0 / u s r / s b i n / mksd / u s r / b i n /
mksscan
8 mab : ~ # mkdir / var / run / mksd
9 mab : ~ # chmod 6 0 0 / var / run / mksd
10 # u r u c h o m i e n i e demona
11 mab : ~ # mksd
12 mksd v1 . 1 5 . 2 ( c ) MkS Sp . z o . o . 2 0 0 2 , 2 0 0 3
13 t r y b p r a c y : scan , l i c z b a procesow : 1
14 i n i c j a l i z u j e mks_vir  a . . .
15 mks_vir w t l e gotowy do p r a c y
Listing 8.7: Instalacja i uruchomienie demona przyspieszającego proces skanowania
Analogicznie jak wcześniej testujemy, czy wszystko działa jak powinno (Listing 8.8).
1 mab : ~ # mksscan e i c a r . com
2 VIR E i c a r . T e s t / r o o t / e i c a r . com
Listing 8.8: Test demona
Teraz kolej na instalację programu Amavis. Jest to narzędzie o dość szerokim spek-
trum możliwości  z jednej strony może pracować jako program antywirusowy albo ska-
ner spamu, z drugiej może być i jednym i drugim jednocześnie. Ogromną zaletą Amavisa
jest możliwość współpracy z innymi aplikacjami, np. z MKS-em.
Na początek pobieramy z Internetu najnowszą wersję programu:
mab:~# wget http://www.ijs.si/software/amavisd/
amavisd-new-20030616-p6.tar.gz
Instalację przeprowadzamy w sposób pokazany na Listingu 8.9
8.3. MKSvir i Amavis 75
1 mab : ~ # t a r - z x v f amavisd-new-20030616-p1 . t a r . gz
2 mab : ~ # cp amavisd-new -20030616/ amavisd / u s r /
s b i n /
3 mab : ~ # cp amavisd-new -20030616/ amavisd . c o n f /
e t c /
4 mab : ~ # chown r o o t : r o o t / u s r / s b i n / amavisd / e t c /
amavisd . c o n f
5 mab : ~ # chmod 7 0 0 / u s r / s b i n / amavisd
6 mab : ~ # chmod 6 0 0 / e t c / amavisd . c o n f
Listing 8.9: Instalacja programu Amavis
W następnym kroku edytujemy plik konfiguracyjny /etc/amavisd.conf. Należy odszukać
linię: @bypass_spam_checks_acl = qw( . ); i odkomentować ją, natomiast poniższą li-
nię zakomentować: #$unix_socketname =  $MYHOME/amavisd.sock ;. Należy także
usunąć wpisy na temat antywirusów (w sekcji @av_scanners =), ale pozostawić wpis
dotyczący MKS-a. Usunąć wpisy zaczynające się od @av_scanners_backup =. W pliku
/etc/postfix/master.cf dopisujemy linię: localhost:10025 inet n - n - - smtpd oraz modyfi-
kujemy następującą z:
smtp inet n - n - - smtpd
na:
smtp inet n - n - - smtpd -o content_filter=smtp-amavis:[127.0.0.1]:10024
oraz dopisujemy w końcowej części pliku:
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
Teraz należy przeładować Postfix a i Amavisa.
mab:~# /etc/init.d/postfix reload
mab:~# /usr/bin/amavisd
W ten sposób został zabezpieczony serwer poczty. Z jednej strony przed wykorzystywa-
niem przez niepowołane osoby do rozsyłania wiadomości, z drugiej strony przed zalewa-
niem skrzynek pocztowych użytkowników przed spamem i zawirusowanymi wiadomo-
ściami.
Rozdział 9
Zapora ogniowa
W wielu dokumentach opisujących firewalle, porównuje się je albo do ściany zabez-
pieczającej jedną część budynku przed ogniem z innej części albo do fosy otaczającej
zamek zabezpieczającą przed intruzami.
I obie analogie są prawdziwe  z jednej strony mają zabezpieczyć sieć wewnętrzną
(lokalną) od sieci zewnętrznej (Internetem) z drugiej firewall ma za zadanie niedopuścić
intruzów do chronionej części sieci (bądz
systemu).
Firewall, z ang. zapora ogniowa, w tym kontekście jawi się jako jedno z najbardziej
efektywnych zabezpieczeń sieciowych. Jego efektywność wynika między innymi z tego,
że tworzy specyficzny, ściśle chroniony fragment sieci, przez który użytkownicy są zmu-
szeni przejść, jeśli chcą dostać się w określone miejsce sieci bądz
jeśli chcą system (sieć)
opuścić. Taki firewall ma dokładnie określone w regułach jakie pakiety mogą wejść do
sieci, jakie hosty mogą się z nią łączyć, a jakie mają być odrzucone. Zatem widać, że jed-
nym z głównych zadań osoby tworzącej firewall jest ścisłe dookreślenie jaki ruch może
być dopuszczalny. Ruch dopuszczalny w takim przypadku będzie definiowany jako ruch
zgodny z polityką bezpieczeństwa danej sieci (systemu).
Podstawową funkcjonalnością prostej zapory ogniowej jest filtrowanie pakietów, i
wtedy może on blokować pakiety na podstawie parametrów:
" adresu docelowego IP;
" adresu z
ródłowego IP;
" portu z
ródłowego i portu z
ródła;
" wykorzystywanego protokołu;
9.1. Firewalle 77
Bardziej zaawansowane zapory ogniowe mogą brać pod uwagę inne parametry, ale nie
przekraczające jednak swoim zasięgiem 4 warstwy OSI  protokołów TCP/UDP. Niestety
takie firewalle nie są w stanie odróżnić ataków przenoszonych przez protokoły wyższych
warstw. I to jest jedna z wad typowych firewalli. W takim przypadku, gdy ataki odbywają
się głównie na wyższych warstwach modelu OSI, pewnym rozwiązaniem mogą być tzw.
firewalle aplikacyjne.
9.1 Firewalle
9.1.1 Filtrowanie pakietów
Filtrowanie pakietów najlepiej stosować do takich operacji, które mają być szybko
wykonywane, w dodatku na pojedynczych pakietach. Najlepiej się sprawdza w sytu-
acjach, gdy trzeba wykryć i odrzucić nielegalne pakiety  np. te przychodzące z sieci
zewnętrznej, ale podające się za pakiety sieci wewnętrznej. Wyróżniamy dwa rodzaje
filtrowania  proste i dynamiczne.
Filtrowanie proste
Są to najprostsze metody filtrowania, które pozwalają na kontrolowanie  akceptowa-
nie bądz
odrzucanie  przepływu danych na podstawie adresu (w tym przypuszczalnego)
z
ródłowego, adresu docelowego oraz portu sesji aplikacji używanego do przesyłania da-
nych.
Samo proste filtrowanie nic nie robi z danymi, ponieważ nie ma dostępu do danych
zawartych przenoszonych w pakietach. Prosty system filtrowania wykonuje tylko zada-
nia: zezwolenie na dostęp do portu, blokowanie portu z określonego adresu z
ródłowego
bądz
do określonego adresu docelowego.
Filtrowanie dynamiczne
To bardziej zaawansowany system filtrowania pakietów, który oferuje przechowywa-
nie stanu protokołów, sprawdzanie protokołów. Stąd takie filtrowanie nazywane jest też
dynamicznym filtrowaniem  zachowanie systemu zmienia się w zależności od widzia-
nego wcześniej ruchu. Bywa też nazywane stanowym filtrowaniem, ponieważ filtr pakie-
tów musi przechowywać stany sesji (np. sesji TCP).
Filtrowanie dynamiczne pozwala zapobiec różnym rodzajom skanowania portów i
blokowania usług, tym samym nie pozwala na dodawane innych protokołów.
9.1. Firewalle 78
Ma ono jednak wady. Ruter (bądz
system pracujący jako ruter) musi pamiętać stany,
co dość mocno może obniżać jego wydajność, a w sytuacjach krytycznych nawet powo-
dować blokowanie działania rutera. Drugą znaczącą wadą jest to, że ruter musi pamiętać
informacje o stanie, przy czym nie ma żadnych gwarancji, że pakiet z odpowiedzią kie-
dykolwiek nadejdzie. W tym przypadku może się zdarzyć, że pakiet przyjdzie po czasie,
gdy ruter usunie regułę pamiętania pakietu i pakiet, który powinien zostać zaakceptowany
zostanie odrzucony. Kolejną, ważną wadą takiego filtrowania jest to, że jest ono bardzo
podatne na fałszowanie adresów. Filtr może zdecydować, że dany pakiet jest odpowie-
dzią, na podstawie adresu z
ródłowego, mimo, że został on sfałszowany.
9.1.2 Systemy pośredniczące
Serwer pośredniczący (proxy server), w przeciwieństwie do systemów filtrowania pa-
kietów, nie opiera swojego działania na pakietach IP, ale na protokołach wykorzystywa-
nych przez aplikacje. Program użytkownika kontaktuje się z takim serwerem zamiast
z  prawdziwym serwerem gdzieś w Internecie. Serwer pośredniczący ocenia żądania
klienta i decyduje, czy je wykonać, czy odrzucić. Jeśli wykonuje żądania, to serwer proxy
porozumiewa się z docelowym serwerem w imieniu klienta i przekazuje dalsze żądania
klienta do serwera, a odpowiedzi serwera do klienta. Porozumiewanie się klienta z proxy
wygląda tak samo jak porozumiewanie się z każdym innym serwerem.
Ważne w tym przypadku jest to, że proxy, jako jedyny porozumiewający się bez-
pośrednio z siecią zewnętrzną, potrzebuje adresu IP. Stąd takie rozwiązanie pozwala na
oszczędzanie przestrzeni adresowej.
W różnych usługach pośredniczenie działa różnie. Część z nich zapewnia je automa-
tycznie, ewentualnie są proste do skonfigurowania  wystarczy wprowadzić odpowied-
nią konfigurację. Jednak znaczna większość wymaga odpowiedniego oprogamowania po
stronie klienta. W takim przypadku musi być spełniony jeden z warunków:
" klient będzie posiadał oprogramowanie aplikacyjne potrafiące współpracować z
serwerem pośredniczącym;
" klient będzie posiadał system operacyjny potrafiący współpracować z serwerem po-
średniczącym;
" klient posiada procedury, które umożliwią współpracę z serwerem proxy;
Jeśli mimo wszystko żaden z powyższych warunków nie jest spełniony po stronie klienta,
9.1. Firewalle 79
może być zastosowany odpowiedni ruter, który będzie obsługiwał połączenie (ruter prze-
chwytuje połączenie i przekierowuje do serwera proxy).
Serwer pośredniczący może wykonywać więcej zadań niż tylko przekazywanie żądań.
Taki inteligentny serwer pośredniczący będzie zapewniał rejestrowanie i lepszą kontrolę
dostępu, niż można by osiągnąć innymi metodami.
9.1.3 Hosty bastionowe
Typowy host bastionowy to system, z którym wszyscy użytkownicy zewnętrzni muszą
się połączyć, aby uzyskać dostęp do określonych systemów bądz
usług.
Jest on z założenia odkryty  Internet wie o jego istnieniu, jest więc najbardziej nara-
żony na ataki, przez co musi być mocno zabezpieczony.
Hosty bastionowe są używane w różnych konfiguracjach i architekturach firewalli.
Można wyróżnić kilka specjalnych rodzajów hostów bastionowych:
" nietrasujace hosty dwusieciowe  posiada wiele połączeń sieciowych, ale nie prze-
kazuje pomiędzy nimi ruchu; może być samym firewallem, albo częścią większej
zapory ogniowej;
" komputery-ofiary  to komputer, w którym nie ma nic wartościowego, nie ma z
niego dostępu do innych maszych, zwykle jest to system z minimalnymi zasobami,
niezbędnymi by świadczyć usługi; są to zwykłe hosty bastionowe ale udostępniają
logowanie do systemu;
" wewnętrzne hosty bastionowe  wchodzi w skład kilku hostów bastionowych, przy
czym zwykle koordynuje dane przesyłane z zewnętrznego serwera do serwera we-
wnętrznego;
" zewnętrzne hosty usługowe  udostępniają usługi w Internecie, są bardzo widoczne
i przez to mają za zadanie brać na siebie cały atak; zwykle mają ograniczony dostęp
do sieci wewnętrznej i nie obsługują użytkowników z sieci wewnętrznej;
Główną zaletą hostów bastionowych jest ich prostota, natomiast wadą fakt, że częściej
niż inne maszyny są narażane na ataki.
9.1.4 Firewalle aplikacyjne
Firewalle aplikacyjne to nowa klasa firewalli, która stosunkowo niedawno pojawiła
się na rynku. Jest to rodzaj filtra, który integruje się warstwą aplikacji, np. z przeglą-
9.2. Iptables 80
darką WWW  przez co działa pomiędzy warstwą sieci i warstwą aplikacji. Dzięki temu
zajmuje się już pakietami po wstępnej obróbce wcześniejszych warstw.
I przykładowo taki firewall działając jako moduł serwera WWW mocno integruje się
z serwerem aplikacji, przez co:
" nie muszą dbać o rozszyfrowanie SSL;
" nie można ich obejść kodując zlecenia;
" mogą być proste  większość pracy wykonuje za nie serwer WWW (rozszyfrowanie
transmisji SSL jeśli jest używana, dekodowanie zleceń, wstępna obróbka zleceń)
Firewalle aplikacyjne, to jak już wspomniałam dość młoda dziedzina informatyki i
wiele z nich nie działa tak jak powinno, do wielu serwerów nie ma napisanych jesz-
cze odpowiednich modułów, a te które już istnieją, zanim będą stosowane, powinny być
wcześniej dobrze przetestowane na konkretnej maszynie.
9.2 Iptables
Przykładem stanowego filtra pakietów, który został wprowadzony w jądrach 2.4.x jest
Iptables.
Mechanizm Iptables został podzielony na moduły   klasy-tablice . I tak zaimple-
mentowano tablice:
" filter  przeznaczona do budowania zapór ogniowych opartych o filtrowanie pakie-
tów, do kontroli i zliczania ruchu w sieci, diagnostyki sieci;
Zbiory reguł tej tablicy to: INPUT  dla pakietów przeznaczonych dla lokalnego
hosta, OUTPUT  dla pakietów pochodzących z lokalnego hosta, FORWARD  dla
pakietów przechodzących przez lokalny ruter.
" nat  przeznaczona głównie do maskowania adresów IP, przekierowywania portów,
budowania przezroczystych PROXY;
Zbiory reguł tej tablicy to: PREROUTING  dla pakietów przychodzących z ze-
wnętrznego hosta, OUTPUT  dla pakietów pochodzących z lokalnego hosta, PO-
STROUTING  dla pakietów wychodzących na zewnątrz hosta.
" mangle  przeznaczona do kontroli przepływu danych  ograniczania pasma;
Zbiory reguł tej tablicy to: PREROUTING  dla pakietów przychodzących z ze-
wnątrz hosta, OUTPUT  dla pakietów pochodzących z lokalnego hosta.
9.2. Iptables 81
Aby użyć tablicy należy podać w linii komend opcję-t.
9.2.1 Stany pakietów
Pakiety mogą przyjmować kilka różnych stanów wewnątrz jądra w zależności od pro-
tokołu jakiego używają. Na zewnątrz jądra, istnieją tylko cztery stany pakietów. Mogą
być używane wraz ze stanami dopasowania, które będą póz
niej zdolne do dopasowania
pakietów bazujących na ich bieżącym połączeniu. Możliwe stany pakietu to:
" NEW (nowy)  oznacza, że pakiet jest nowy w połączeniu (pierwszy pakiet wędru-
jący do hosta);
" ESTABLISHED (ustalony)  ruch pakietów odbywa się w obu kierunkach; połącze-
nie NEW przyjmuje status ESTABILISHED, gdy po wysłaniu pierwszego pakietu
nadeszła nań odpowiedz
;
" RELATED (spokrewniony)  pakiet jest spokrewniony w pakietami w stanie ES-
TABILISHED; gdy pakiet ESTABILISHED daje początek nowemu połączeniu, to
nowy pakiet przechodzi w stan RELATED;
" INVALID (błędny)  pakiet nie może być zidentyfikowany, bądz
nie posiada żad-
nego stanu, przyczyną takiego stanu pakietu może być np. przepełnienie pamięci
systemu;
9.2.2 A
ańcuchy
A
ańcuch (z ang. chain) to lista reguł, z których każda określa działanie jakie zosta-
nie podjęte na podstawie nagłówka pakietu. Jeżeli dana reguła nie pasuje do pakietu, to
sprawdzana jest następna. Jeśli żadna z reguł nie pasuje, wtedy stosowana jest reguła
domyślna (policy) dla danego łańcucha. Dobrze zabezpieczany system, powinien stoso-
wać się do reguły, że jeśli żadna reguła nie pasuje do nagłówka pakietu, to pakiet będzie
odrzucony.
Na całych łańcuchach mogą być wykonywane operacje:
" -N stworzenie nowego łańcucha;
" -X usunięcie pustego łańcucha;
" -P zmiana reguły dla wbudowanego łańcucha;
9.2. Iptables 82
" -L wylistowanie reguł w łańcuchu;
" -F wyczyszczenie reguł z łańcucha;
" -Z  wyzerowanie liczników pakietów i bajtów we wszystkich regułach w łańcu-
chu;
Operacje dozwolone na regułach w środku łańcucha:
" -A dodanie nowej reguły do łańcucha;
" -I wstawienie nowej reguły na wskazanej pozycji w łańcuchu;
" -R wymiana reguły na wskazanej pozycji w łańcuchu
" -D skasowanie pierwszej pasującej reguły z łańcuchu
9.2.3 Dopasowania
Dopasowania ogólne
Są rodzajem dopasowań, które są zawsze dostępne niezależnie od rodzaju pracującego
protokołu czy załadowanych dopasowań rozszerzonych. Do załadowania dopasowania
ogólnego, nie są wymagane żadne dodatkowe parametry. Najważniejsze dopasowania
ogólne to:
" -p  używane do sprawdzania protokołów; protokół może być podany jako war-
tość; podana wartość może zawierać znak negacji, co będzie oznaczało  wszystkie
porotokoły poza tym jednym ;
" -s  oznacza z
ródło pochodzenia pakietów; domyślnie oznaczane są wszystkie
pakiety IP, ale gdy podamy przed z
ródło znak negacji, będzie to znaczyć  wszystkie
z
ródła poza tym jednym ;
" -d oznacza miejsce przeznaczenia pakietów; analogicznie jak dla-sstosuje się
negację;
" -i  oznacza interfejs, z którego pochodzą pakiety; to dopasowanie jest zgodne
tylko z łańcuchami PREROUTING, FORWARD i INPUT; wpis może zawierać znak
negacji, co będzie oznaczało  wszystkie interfejsy poza określonym ;
9.2. Iptables 83
" -o oznacza interfejs do którego mają trafić pakiety; to dopasowanie pasuje tylko
do łańcuchów FORWARD, OUTPUT, POSTROUTING; analogicznie jak dla dopa-
sowania-istosuje się negację;
" -f  oznacza drugą i kolejne fragmenty podzielonych pakietów; są oznaczane,
gdyż nie ma innej możliwości przekazania do miejsca przeznaczenia lub pochodze-
nia informacji o pakietach; gdy będzie użyta negacja, wtedy oznacza to pierwszy
fragment podzielonego pakietu;
Dopasowania pośrednie
Istnieją trzy typy dopasowań pośrednich, które są ładowane automatycznie dla róż-
nych protokołów. Są to:
" Dopasowania TCP  są określone dla protokołu TCP, dostępne są tylko wtedy, gdy
pracują wraz z pakietami i strumieniami TCP; aby użyć to dopasowanie, w linii
komend trzeba podać dodatkowo-p tcp;
" Dopasowania UDP  są określone dla protokołu UDP, dostępne są tylko wtedy, gdy
pracują wraz z pakietami UDP; aby użyć to dopasowanie, w linii komend trzeba
podać dodatkowo-p udp
" Dopasowania ICMP  są określone dla protokołu ICMP, dostępne są tylko wtedy,
gdy pracują wraz z pakietami ICMP; aby użyć to dopasowanie, w linii komend
trzeba podać dodatkowo-p icmp;
Dopasowania wyraz
ne
Są to dopasowania specjalne, które muszą być ładowane z opcją-match. Niektóre
z nich są specyficzne dla określonych protokołów, w innych są wykorzystywane testowo.
Jednak wszystkie te dopasowania i ich wykorzystanie mogą nie być użyteczne. Różnica
między dopasowaniami pośrednimi i wyraz
nymi polega na tym, że pośrednie są ładowane
automatycznie, natomiast wyraz
ne trzeba ładować przed każdym uruchomieniem.
Dopasowania MAC
Ten rodzaj dopasowania jest stosowany do dopasowywania pakietów, których pod-
stawą jest adres sprzętowy MAC. Aby użyć to dopasowanie konieczne jest określenie w
linii komend-m mac.
9.2. Iptables 84
Dopasowania limitujące
Są stosowane do ograniczenia zapisu dzienników na określonych regułach. Oznacza
to tyle, że za pomocą tego dopasowania można ograniczać to, jak wiele razy pewna reguła
może być dopasowana do pewnego okresu czasu. Aby użyć to dopasowanie, w linii
komend trzeba podać dodatkowo-m limit.
Dopasowania wieloportowe
Służą one do określenie większej ilości portów przeznaczenia i zasięgu portów więcej
niż jeden. Zwykle są stosowane przy budowaniu identycznych reguł, ale przeznaczonych
dla różnych portów. Aby użyć to dopasowanie należy podać-m multiport.
Dopasowania zaznaczające
Są stosowane do dopasowania pakietów na podstawie zaznaczeń, które mają usta-
wione. Zaznaczenie jest specjalnym polem utrzymywanym wewnątrz jądra, które jest
kojarzone z pakietami. Mogą być one użyte przez różne układy jądra dla takich zadań jak
ruch formujący i filtrowanie. Pole zaznaczenia jest obecnie ustawione na liczbę całkowitą
typu unsigned. Do użycia tych dopasowań należy określić w linii komend dopasowanie
-m mark.
Dopasowania własnościowe
Są używane do dopasowania pakietów na podstawie ich właścicieli. To dopasowanie
pracuje tylko z łańcuchem OUTPUT. Do użycia tych dopasowań należy określić w linii
komend dopasowanie-m owner.
Dopasowania stanu
Są stosowane wraz z kodem śledzonego połączenia w jądrze i pozwalają na dostęp do
stanu pakietów śledzonego połączenia. Do użycia tych dopasowań należy określić w linii
komend dopasowanie-m state.
Dopasowania TOS
Są używane do dopasowania pakietów na podstawie pola TOS (Type Of Service). Ro-
dzaj usługi (TOS) składa się z 8 bitów i znajduje się w nagłówku IP. TOS jest używane do
9.2. Iptables 85
poinformowania pośrednich poprzedzających hostów o strumieniu i rodzaju zawartości.
Do użycia tych dopasowań należy określić w linii komend dopasowanie-m tos.
Dopasowania TTL
Są używane do dopasowania pakietów na podstawie ich pola TTL (Time-To-Live),
które znajduje się w nagłówku IP. Pole TTL składa się z 8 bitów i jego wartość jest
obniżana za każdym razem, gdy pakiet przechodzi przez pośrednie hosty. Aby użyć tych
dopasowań należy określić w linii komend dopasowanie-m ttl.
9.2.4 Cele i skoki
Są używane do przekazywania reguł dotyczących pakietów, które pasują do konkret-
nego dopasowania. Skok jest dokładnie tym samym, co cel, z tą różnicą, że wymaga
łańcucha wewnątrz tej samej tablicy do której ma być wykonany skok. Aby zastosować
w danej regule skok lub cel należy użyć opcji-j. Stosuje się następujące cele:
" ACCEPT  nie posiada specjalnych opcji; jeśli pakiet pasuje dokładnie do danego
dopasowania i ustawiony jest na cel ACCEPT, zostaje zaakceptowany i nie kon-
tynuuje wędrówki poprzez łańcuch od miejsca z którego został zaakceptowany;
jeśli pakiet został zaakceptowany w jednym łańcuchu wędruje przez inne łańcuchy,
gdzie może być odrzucony;
" DROP  odrzuca pakiety i odmawia dalszego ich przetwarzania; jeśli pakiet pasuje
do dopasowania z użytym celem DROP wtedy zostanie zablokowany i żadne inne
działanie na nim nie będzie podejmowane;
" QUEUE  używany do kolejkowania pakietów w drodze do programów i aplikacji
użytkowników; wykorzystywany w zastosowaniach programistycznych (np. może
być wykorzystywany do zliczania ruchu sieciowego, albo tworzenia bardziej za-
awansowanych filtrów pakietów);
" RETURN  powoduje przerwanie  wędrówki pakietu w miejscu, gdzie znajduje
się dana reguła; jeśli reguła jest podłańcuchem innego łańcucha, pakiet będzie wę-
drował przez strukturę łańcuchów; jeśli łańcuch w którym występuje RETURN jest
łańcuchem głównym, wtedy na pakiecie zostanie wykonana domyślna polityka łań-
cucha (najczęściej DROP lub ACCEPT);
9.3. Przykładowy Firewall 86
" LOG  stosowany jest do zapisywania informacji o pakietach, które nie są dozwo-
lone, bądz
też do wyszukiwania błędów w procesie filtrowania; zawiera w sobie
takie informacje jak nagłówek IP, które mogą być czytane przez DMESG lub SY-
SLOGD; ten cel idealnie nadaje się do rozwiązywania problemów z ustalonymi
regułami;
" MARK  stosowany jest do ustawiania wpisów wartości, które są skojarzone z okre-
ślonymi pakietami; może być używany tylko do tablicy mangle;
" REJECT  działa tak samo jak DROP, z tą różnicą, że wysyłana jest z powro-
tem wiadomość o błędzie do hosta wysyłającego pakiet, który został zablokowany;
współpracuje tylko z łańcuchami INPUT, FORWARD, OUTPUT;
" MIRROR  sprawia, że w nagłówku IP zostaje zamienione pole nadawcy z polem
odbiorcy, w wyniku czego pakiety wracają do do hosta, który pakiety przysłał;
" SNAT  może być zdefiniowany tylko dla łańcucha POSTROUTING tablicy nat;
sprawia, że dla danego pakietu zostaje zmieniony adres z
ródłowy;
" DNAT  może być stosowany tylko dla tablicy nat; powoduje, że dla danego adresu
zostaje zmieniony adres docelowy;
" MASQUERADE  zdefiniowany jest tylko dla łańcucha POSTROUTING tablicy nat
i powoduje, że dla danego pakietu zmieniany jest adres z
ródłowy; różnica między
nim a SNAT polega na tym, że w MASQUERADE adres z
ródłowy jest zmieniany na
adres interfejsu na który pakiet zostanie przekierowany; MASQUERADE może być
stosowany przy dynamicznym przydzielani u adresów IP;
" REDIRECT  stosowany jest do przeadresowania pakietów i strumieni danych;
9.3 Przykładowy Firewall
Poniżej omówię prostą zaporę ogniową, stworzoną ma bazie Iptables. Aby zapora
mogła działać musi być stworzony odpowiedni wykonywalny skrypt uruchamiany przez
proces init  wtedy ustawienia lokalnej zapory, przy każdorazowym uruchomieniu sys-
temu będą automatycznie ustawiane.
Gwoli przypomnienia należy dodać, że firewalle oparte na Iptables będą działały tylko
na jądrach wersji 2.4.x, a używanie w tablicy mangle reguł input, forward i output jest
9.3. Przykładowy Firewall 87
możliwe dla jąder od wersji 2.4.18. Poniższy skrypt podzieliłam na mniejsze części, tak
by łatwiej było opisać, jakie zadania dana część wykonuje.
Na początek należy w skrypcie podać kilka informacji opisujących nasz firewall. Uru-
chamiamy firewall, podajemy ścieżkę do Iptables, porty, które mają być przekazywane
oraz zakres sieci.
1 # ! / b i n / bash
2 # ppp0ś -- w i a t
3 # e t h 0 -- l o k a l n y
4 echo -n " S t a r t i n g f i r e w a l l . . . "
5 echo " "
6 IPT=" / s b i n / i p t a b l e s "
7 FPORTY="
2 1 , 2 0 , 2 5 , 8 0 , 5 3 , 1 1 0 , 4 4 3 , 6 6 6 7 , 6 6 6 8 , 6 6 6 9 , 8 0 7 4 "
8 LAN=" 1 9 2 . 1 6 8 . 1 . 0 / 2 4 "
Czyścimy wszystkie reguły w łańcuchach:
1 $IPT -F
2 $IPT -F - t n a t
Całkowicie blokujemy dostęp z Internetu:
1 $IPT -P INPUT DROP
2 $IPT -A INPUT - i l o - j ACCEPT
Zezwalamy na dostęp do ściśle określonych przez nas portów:
1 #SMTP
2 $IPT -A INPUT -p t c p -- d p o r t 25 - d 0 / 0 - j
ACCEPT
3 #FTP
4 $IPT -A INPUT -p t c p -- d p o r t 21 - d 0 / 0 - j
ACCEPT
5 #SSHD
6 $IPT -A INPUT -p t c p -- d p o r t 22 - d 0 / 0 - j
ACCEPT
7 #HTTP
8 $IPT -A INPUT -p t c p -- d p o r t 80 - d 0 / 0 - j
ACCEPT
9.3. Przykładowy Firewall 88
9 # S e c u r e HTTP
10 $IPT -A INPUT -p t c p -- d p o r t 443 - d 0 / 0 - j
ACCEPT
11 #POP3
12 $IPT -A INPUT -p t c p -- d p o r t 110 - d 0 / 0 - j
ACCEPT
13 #ICQ
14 $IPT -A INPUT -p t c p -- d p o r t 5000:5 100 - d 0 / 0 -
j ACCEPT
Zezwalamy na przychodzące połączenia zainicjowane przez nasz serwer:
1 $IPT -A INPUT -m s t a t e -- s t a t e ESTABLISHED ,
RELATED - j ACCEPT
Zezwalamy wybranym hostom na dostęp do FTP i SSH:
1 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 2 - p t c p -- d p o r t
20 - j ACCEPT
2 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 2 - p t c p -- d p o r t
22 - j ACCEPT
3 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 2 - p udp -- d p o r t
22 - j ACCEPT
4 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 2 - p t c p -- d p o r t
23 - j ACCEPT
Potrzebne dla DNAT, czyli pozwalamy aby wychodziło w świat.
1 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 2 - p t c p -- s p o r t
22 - j ACCEPT
2 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 8 - p t c p -- s p o r t
20 - j ACCEPT
3 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 8 - p t c p -- s p o r t
22 - j ACCEPT
4 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 8 - p udp -- s p o r t
22 - j ACCEPT
5 $IPT -A FORWARD - s 1 9 2 . 1 6 8 . 1 . 8 - p t c p -- s p o r t
23 - j ACCEPT
9.3. Przykładowy Firewall 89
Pozwalamy aby cały ruch z serwera nie był blokowany:
1 $IPT -P OUTPUT ACCEPT
Zabezpieczenie przed powodzią SYN (Syn-flood)
1 $IPT -A FORWARD -p t c p --syn -m l i m i t -- l i m i t
1 / s - j ACCEPT
Przekierowania DNAT:
1 $IPT - t n a t -A PREROUTING -p t c p -- d p o r t 9999 -
i ppp0 - j DNAT -- t o 1 9 2 . 1 6 8 . 1 . 2 : 2 2
Koniec skryptu:
1 echo -n " F i r e w a l l done . "
2 echo " "
9.3.1 Podsumowanie
Przedstawiony przykład zapory ogniowej, to typowy firewall filtrujący, w którym za-
stosowano politykę bezpieczeństwa polegającą na udostępnieniu określonych usług, przy
jednoczesnym zablokowaniu wszystkich tych, które nie są wykorzystywane.
Może wydawać się, że to prosty firewall, ale tak nie jest. Dzięki temu, że wyko-
rzystuje stany pakietów ESTABILISHED i RELATED zezwalamy na połączenia, które są
odpowiedzią na połączenia inicjowane przez nasz serwer.
Ten firewall pełni także funkcję zapory pośredniczącej  pakiety pochodzące z sieci
wewnętrznej (lokalnej) i przychodzące do niej z sieci zewnętrznej muszą przejść przez
serwer, zanim trafią do adresata.
Rozdział 10
Wykrywanie intruzów
Rozsądne czytanie dzienników, tzw. logów pomaga utrzymywać stabilny stan sys-
temu. Wszelkie dodatkowe automatyczne monitorowanie i system powiadamiania bardzo
ułatwiają pracę administratorowi, jednocześnie zmuszając go do regularnego przegląda-
nia systemu pod kątem bezpieczeństwa.
Może się jednak zdarzyć, że te dzienniki zostaną sfałszowane. Aby temu zapobiec
powinno się stosować system wykrywania intruzów tzw. IDS1. Najprostsze systemy tego
typu monitorują jeden komputer, poprzez sprawdzanie najważniejszych plików systemo-
wych pod kątem zgodności z przechowywanymi sumami kontrolnymi i alarmowanie, gdy
nastąpi jakaś nieoczekiwana zmiana w tych plikach.
Bardziej złożone są sieciowe systemy wykrywania intruzów  NIDS2. Mogą nie tylko
sprawdzać zgodność plików z sumami kontrolnymi, ale także alarmują o atakach po-
tencjalnie przeprowadzanych w danej chwili. NIDS potrafi także przewidywać atak na
podstawie bazy danych zawierającej znane symptomy ataków, a nawet na podstawie róż-
nicy między obecnym stanem sieci a stanem jej normalnym (takim, który NIDS traktuje
za normalny). Przykładem takiego złożonego narzędzia do monitoringu systemu i sieci
jest program Snort, którym zajmę się w dalszej części tego rozdziału.
10.1 Sprawdzanie integralności
Sprawdzanie integralności polega na tworzeniu i utrzymywaniu chronionej bazy da-
nych, w której zawarte są wszelkie sumy kontrolne i inne rzeczy związane z ważnymi
plikami systemowymi.
1
Intrusion Detection Systems
2
Network Intrusion Detection Systems
10.2. Poszukiwanie i wykrywanie anomalii 91
Dobrze jest, gdy taka baza przechowywana jest na partycji tylko do odczytu, na innym
komputerze, albo na całkowicie innym nośniku, na którym dane nie mogą podlegać już
modyfikacji.
Narzędzie sprawdzające porównuje dane zawarte na nośniku z tymi w systemie i
wszelkie anomalie traktuje jako próbę ataku. W dzienniku zapisywany jest odpowiedni
komunikat.
Regularnie sprawdzając dzienniki, będące wynikiem pracy narzędzi sprawdzających
integralność, znacząco zmniejsza się prawdopodobieństwo włamania do systemu. Im
krótszy jest czas między próbą włamania a odkryciem tego faktu, tym większe prawdo-
podobieństwo, że administrator złapie, bądz
przynajmniej wyrzuci intruza z systemu, a
tym samym nie zostaną w systemie wyrządzone duże szkody.
Samo sprawdzanie nie jest trudnym zadaniem  to tylko stwierdzenie faktu, że plik,
który nie powinien został zmodyfikowany.
Sprawdzanie integralności nie jest działaniem bezpośrednio zabezpieczającym  jego
zadanie to wykrywanie prób ataku, bądz
samego ataku. Sam system IDS (NIDS) nie
zabezpieczy odpowiednio systemu. O to musi zadbać sam administrator używając odpo-
wiednich narzędzi.
10.2 Poszukiwanie i wykrywanie anomalii
Poszukiwaniem i wykrywaniem anomalii już nie tylko w obrębie jednego komputera,
ale i sieci doń podłączonej zajmują się złożone narzędzia NIDS.
Badają one stan otoczenia komputera (sieci) i starają się to uzgodnić z bazą danych za-
wierającą różne objawy ataków. Nie wymagają one dużego nakładu pracy od administra-
tora  jedynie w miarę regularnego uaktualniania bazy symptomów ataków. Oczywiście
może się pojawić pewien procent fałszywych alarmów, ale jest on bardzo niewielki.
Ten sposób wykrywania intruzów w systemie, czy sieci jest bardzo skuteczny i często
praktykowany. Jedynym jego znanym ograniczeniem jest skończona baza symptomów,
z którą porównywane są anomalie  baza powstaje jako wynik przeprowadzonych już
ataków.
Istnieją także systemy wykrywające same anomalie w sieci. Nie są jednak one do-
skonałe, z tego względu, że ciężko jest jednoznacznie określić co to jest normalny ruch w
sieci. Sam administrator może mieć problem z dokładnym sprecyzowaniem tego pojęcia,
a co dopiero program. Te, które jednak są zaimplementowane z reguły są dość wolne.
Muszą wpierw zebrać dużą ilość danych dotyczących stanu sieci, poddać je obróbce sta-
10.3. Snort 92
tystycznej, stworzyć tzw. normalny statystyczny profil sieci. Taki system wymaga nie-
kończącego się dostrajania, ze względu na ciągle zmieniające się warunki w sieciach.
Dużą wadą takiego systemu, dość mocno dyskwalifikującą ją z ciągłej pracy, jest duży
procent generowanych fałszywych alarmów, co stanowi niejednokrotnie wiele kłopotów.
Niemniej przed tymi właśnie sposobami monitorowania stanu sieci i wykrywania ano-
malii rysuje się duża przyszłość, choćby tylko ze względu na to, że narzędzia wykrywa-
jące oznaki ataku ograniczają się tylko do już znanych metod ataku.
10.3 Snort
Snort to jeden z najlepszych wolnodostępnych systemów NIDS. Jego największą za-
letą jest wszechstronność. Może pracować jako analizator protokołów (ang. sniffer), tyle
że dużo szybszy niż np. tcpdump i dużo bardziej przyjazny niż wiele innych podobnych
mu systemów. Snort potrafi rejestrować pakiety w dziennikach systemowych, prowadzić
niepełny dziennik nadzoru ruchu sieciowego, śledzić pakiety według nazw hostów i se-
gregować rejestrowane pakiety w symbolicznych blokach. Jest to także system, który w
100% daje się dostosować do indywidualnych potrzeb. Posiada zarówno gotową biblio-
tekę przygotowanych symptomów ataków, jak i mechanizm tworzenia własnych reguł,
który jest w pełni kontrolowany przez użytkownika.
Snort może pracować w trzech trybach:
" sniffer  odczytuje pakiety z interfejsu sieciowego i wypisuje je na standardowe
wyjście.
" packet logger  odczytuje pakiety z interfejsu sieciowego i zapisuje na dysk.
" network intrusion detection  dokonuje analizy pakietów i wykonuje odpowiednią
akcję.
10.3.1 Sniffer
Snort z doskonałym skutkiem może być wykorzystywany jako narzędzie do prze-
chwytywania pakietów. I nie trzeba go w tym celu specjalnie konfigurować. Wystarczy
uruchomić program z odpowiednimi flagami. W tym trybie Snort uruchamiany jest z
opcjami:
" -v wyświetla nagłówki IP/TCP/UDP/ICMP;
10.3. Snort 93
" -d dekoduje dane warstwy aplikacji;
" -i wyświetla opis interfejsu;
" -e wyświetla dane warstwy łącza danych;
Po fladze-ipowinno się podawać nazwę interfejsu ethernetowego na którym mają być
przechwytywane pakiety. Jeśli system posiada tylko jeden interfejs sieciowy to flagę tę
można pominąć.
I tak w tym trybie działanie programu można wywołać poleceniem:
mab:~# snort -vde -i eth0
Jeśli chcemy, by Snort przechwytywał wszystkie pakiety poza pakietami Secure Shell
(serwery SSH prowadzą nasłuch na porcie 22) wtedy polecenie będzie miało postać:
mab:~# snort -dv not port 22
10.3.2 Packet logger
Snort może być również wykorzystany do rejestrowania pakietów  uruchomiony w
trybie przechwytywania pakietów będzie generowany wynik zapisywał do pliku teksto-
wego. W tym trybie Snort wykorzystuje flagi:
" -l dodaje katalog, w którym będzie zapisywany dziennik, a następnie wprowa-
dza program w tryb rejestrowania pakietów; jeśli podany w poleceniu katalog nie
istnieje program zakończy działanie błędem;
" -h pozwala określić własną sieć home, Snort będzie traktował każdy adres IP z tej
sieci jako kliencki i nazwy katalogów poświęconych tym hostom będzie nadawał
od ich adresów IP;
" -b pozwala na rejestrowanie wszystkiego w jednym pliku, dzięki tej fladze Snort
zyskuje znacznie na wydajności i generalnie taki sposób rejestrowania nadaje się
idealnie do szybkich sieci;
" -r dokonuje konwersji pliku na format ASCII i wyświetla go na ekranie;
10.4. Konfiguracja Snorta 94
10.3.3 Network intrusion detection
Ten tryb zostaje aktywowany poprzez podanie flagi -c i nazwy pliku konfiguracyj-
nego. W przypadku, gdy nie została podana opcja-ldane będą zapisywane do /var/lo-
g/snort/.
Dodatkowo w tym trybie wykorzystywane są flagi:
" -T powoduje testowanie konfiguracji;
" -D program ma pracować w trybie demona
" -zest  Snort ma ignorować pakiety TCP, które nie są częścią ustanowionych
sesji;
" -A wybór trybu ostrzegania;
Snort posiada sześć trybów ostrzegania:
" full  jest trybem domyślnym;
" fast  rejestruje czas, komunikat ostrzegawczy, adresy IP oraz porty hosta z
ródło-
wego i docelowego;
" socket  przesyła komunikat przez gniazda UNIX do innego programu;
" syslog  przesyła komunikaty do syslog;
" smb  pozwala na przesyłanie komunikatów przez protokół smb do odpowiednich
komputerów, których nazwy są wpisane do pliku lista_maszyn3;
" none  wyłącza ostrzeganie
10.4 Konfiguracja Snorta
Plik konfiguracyjny programu to /etc/snort/snort.conf, ale nie jest to ściśle określone
 Snort tego nie wymaga. Jego konfiguracja jest modułowa i składa się z:
" definicji zmiennych, które definiują domyślne wartości;
" przetwarzanych wstępnie instrukcji rozszerzeń o moduły dodatkowe
3
stosuje się wtedy dodatkową opcję-M lista_maszyn
10.4. Konfiguracja Snorta 95
" instrukcji wyjściowych
" reguł  ze względu na to, że dość często są uaktualniane reguły oraz dodawane
nowe, Ta część konfiguracji nie powinna znajdować się bezpośrednio w pliku snort.conf;
dobrze jest przenieść reguły do osobnego pliku, a nawet specjalnego katalogu  ru-
les.
10.4.1 Podsumowanie
Zbiór reguł pisany przez autorów programu jest uaktualniany średnio co 30 minut i
automatycznie udostępniany na stronie: http://www.snort.org/dl/snapshot. Jest napisa-
nych wiele skryptów, które pozwalają na automatyczne uaktualnianie zbioru reguł i są
one dostępne w sieci.
Podsumowując widać, że system Snort można bez większych trudności dostosować
do własnych potrzeb, można pisać własne reguły, a można też korzystać z już napisanych
i umieszczonych na stronie domowej systemu. Stąd uważam, że system idealnie nadaje
się do monitorowania bezpieczeństwa praktycznie każdego systemu w sieci.
Rozdział 11
Zakończenie
W pracy zrealizowałam zamierzony cel  opisałam, w sposób praktyczny, stricte in-
żynierski sposoby zabezpieczania systemu Linux.
Wszelkie opisane w pracy testy, wymienione listingi oraz pokazane zrzuty ekranów
są wynikiem autentycznych działań wykonanych na próbnym systemie.
Do zainstalowania i uruchomienia tego systemu wykorzystałam maszynę wirtualną
VMware Workstation v. 4.0.5 build-60301. Sam system, Debian Woody (ostatnia stabilna
wersja systemu), pracujący na jądrze w wersji 2.4.18-bf2.4 (ta wersja jądra jest dostępna
na pierwszej płycie instalacyjnej systemu), został zainstalowany i skonfigurowany do-
kładnie w taki sposób, w jaki opisuję w pracy.
Cała praca dotyczy bezpieczeństwa systemu. Przykłady podane w pracy mają za-
stosowanie tylko w systemie Linux, choć nie ma tak naprawdę znaczenia, czy jest to
Debian, Mandrake, czy Slackware. Różnice pomiędzy tymi systemami polagają głównie
na innym położeniu plików konfiguracyjnych oraz innym sposobie instalacji pakietów 
Debian używa apt-get, Mandrake rpmDrake, a użytkownicy Slackware kompilują z
ródła
pakietów. Bardziej znaczących różnic między nimi nie ma. Zwykły użytkownik, pracu-
jący w środowisku graficznym, np. w KDE nie będzie odczuwał najmniejszej różnicy
między pracą w dystrybucji Debian i dystrybucji Mandrake.
Ogólne informacje jakie przytoczyłam omawiając poszczególne zagadnienia bezpie-
czeństwa w systemie mogą być wykorzystywane przez użytkowników innych systemów.
Przykładowo omawiając problem haseł w systemie opisuję sposób na dobre hasła, który
równie dobrze może być wykorzystywany w systemach MS Windows.
Szczegółowe informacje, jakie zawarłam w pracy omawiają cały zakres bezpieczeń-
stwa systemu.
1
http://www.vmware.com
Zakończenie 97
Istnienie systemu rozpoczyna się od jego instalacji. Jednak już przy instalacji trzeba
pamiętać o wielu istotnych sprawach np. o odpowiednim partycjonowaniu dysku czy też
przemyślanym doborze systemu plików. Przy instalacji systemu zostaje też określone za
pomocą jakiego algorytmu hasła będą kodowane oraz w jaki sposób będą przechowywane
w systemie.
Kiedy mowa o hasłach, to od razu nasuwa się problem fizycznego dostępu bezpośred-
niego do komputera, a z nim odpowiednia konfiguracja programu rozruchowego, w tym
przypadku LILO, oraz samego zabezpieczenia na poziomie sprzętowym w BIOSie.
Logicznym następstwem będzie próba zdalnego wykorzystywania komputera. Użyć
SSH czy transmisji niekodowanej przez Telnet? W jaki sposób zdalnie uruchomić środo-
wisko graficzne? Czy w ogóle można uruchamiać je zdalnie? Jeśli można, to jak zrobić
by było to bezpieczne? Tymi problemami zajęłam się w pracy.
Obecnie gro systemów pracuje w sieci, a w tej sytuacji pojawiają się nowe problemy
 ataki na system. Mogą polegać na sprowadzeniu systemu do stanu, gdy następuje tzw.
 odmowa usługi czy  przepełnienie bufora . Pakiety, które system odbiera mogą mieć
zmieniony nagłówek  fałszywe z
ródło pakietów. Inny sposób ataku, to próba przejęcia
systemu. To można przeprowadzić poprzez różne sposoby podszywania się  wykorzy-
stując metodę  non-blind spoofing ,  Man In the Middle Attack czy też poprzez sfałszo-
wanie adresu MAC. Można zapobiec tym atakom i w pracy opisałam jak tego dokonać.
Kiedy mówimy o Internecie, zwykle myśli się o jego praktycznym wykorzystaniu,
np. poprzez wysyłanie i odbieranie poczty elektronicznej. Ostatnie lata spowodowały
jednak, że konieczne jest, oprócz wykorzystywania dobrego i elastycznego w konfigura-
cji serwera poczty (w pracy opisany jest doskonały MTA  Postfix), stosowanie programu
antywirusowego (w pracy zaproponowałam rodzimej produkcji aplikację MKSvir) i anty-
spamowego (na przykład opisany w pracy Amavis).
Jednym ze sposobów uodparniania się na ataki z zewnątrz to stosowanie zapór ognio-
wych, tzw. firewalli. W pracy opisałam rodzaje firewalli oraz podałam w jakich przy-
padkach należy stosować określony rodzaj zapory. Napisany przeze mnie przykładowy
firewall wykorzystuje Iptables  stanowy filtr pakietów. Jest to przykład zapory, która
spełnia dwojaką funkcję  z jednej strony jest typowy firewall filtrujący, z drugiej jest
zaporą pośredniczącą.
Innym sposobem na zabezpieczanie się przed atakami jest ciągłe monitorowanie sys-
temu, sprawdzanie jego integralności oraz reagowanie na pojawiające się anomalie. Taki
monitoring może prowadzić, opisany w pracy, system Snort.
Zebrane w pracy wiadomości nie wyczerpują całkowicie tematu. Nie jest to po prostu
Zakończenie 98
możliwe  zawsze istnieje możliwość, że pojawi się nowa technika włamań, a z nią nowy
sposób zabezpieczania systemu.
Systemy operacyjne bardzo szybko ewoluują. Przykładem może być Debian, który w
ciągu swojego 10-cio letniego istnienia stał się jednym z najwygodniejszych, w konfigu-
racji i użytkowaniu, systemów. Z początkowej formy czysto tekstowego systemu obecnie
wykorzystuje imponujące graficzne środowiska, takie jak KDE czy GNOME. Z trudnego
i nieprzystępnego zwykłemu użytkownikowi instalatora zrobiono jeden z najprostszych
instalatorów systemu, który jest w stanie  przejść nawet bardzo początkujący użytkow-
nik Linuksa.
Co więcej, mimo tak bardzo przyjaznego interfejsu, prostej konfiguracji, system ten
nie zatracił swojej idei bycia systemem bardzo bezpiecznym.
Jak już wspomniałam w pracy, zagadnienia bezpieczeństwa systemów i sieci są nigdy
nie kończącą się rywalizacją między osobami, które zabezpieczenia tworzą oraz tymi,
którzy próbują je obejść. I w taki sposób będą się one pod tym kątem rozwijać. Ktoś
będzie tworzył nowy sposób przed jakimiś wyimaginowanymi atakami, ktoś inny będzie
próbował to obejść. I odwrotnie  powstanie nowy sposób ataku, wykorzystujący nowe
możliwości systemu, a niedługo póz
niej zostanie wymyślony sposób na zabezpieczenie
tej  dziury .
Dlatego jeśli ktoś chce zajmować się problemami bezpieczeństwa systemów, w szcze-
gólności systemu Linux, powinien regularnie czytać wszelkiego rodzaju informacje o po-
jawiających się w systemie błędach, o najnowszych aktualizacjach poszczególnych pa-
kietów w systemie.
Bibliografia
[1] R. Flickinger, Serwer linuksowy okiem hakera, RM, Warszawa 2003.
[2] G. Musumeci, M. Loukides, Optymalizacja systemów komputerowych, RM, War-
szawa 2002.
[3] D. Atkins, Bezpieczeństwo Internetu, LT&P, Warszawa 1997.
[4] M. Bauer, Linux  bezpieczeństwo serwerów, RM, Warszawa 2003.
[5] J. Forristal, J. Traxler, Hack proofing, Helion, Gliwice 2003.
[6] W. von Hagen, Systemy plików w Linuksie, Helion, Gliwice 2002.
[7] A. Frish, Unix. Administracja systemu, wyd. 3, RM, Warszawa 2003.
[8] P. Wainwright, Apache 2.0 dla zaawansowanych, Helion, Gliwice 2003.
[9] E. Zwicky, S. Cooper, D. Chapman, Internet Firewalls. Tworzenie zapór ogniowych,
RM, Warszawa 2001.
[10] B. Hatch, J. Lee, G. Kurtz, Hakerzy w Linuksie, wydanie drugie, Translator, War-
szawa 2003.
[11] B. Schneier Kryptografia dla praktyków, WNT, Warszawa 2002.
[12] W. Dworakowski, Zabezpieczanie aplikacji internetowych za pomocą firewalli apli-
kacyjnych, VIII seminarium PLOUG, Warszawa.
[13] W. Dworakowski, Najnowsze trendy w dziedzinie zabezpieczeń sieci informatycz-
nych. Firewalle aplikacyjne, IPS, IDS in-line, IX Konferencja PLOUG, Kościelisko.
[14] J. Fisher, Securing X Windows, CIAC-2316 R.O, 1995.
BIBLIOGRAFIA 100
[15] Strona omawiająca zagadnienia związane z konfiguracją systemu Linux:
http://linio.terramail.pl/, w tym artykuły: Postfix+SASL, Postfix  podstawy konfi-
guracji.
[16] Polska strona użytkowników Debiana: http://www.debianusers.pl/, w tym artykuły:
G. Jonczyk Postfix  szybki start, P. Tęcza Praktyczny podręcznik do systemu Debian
GNU/Linux.
[17] Mini-Portal poświęcony systemowi operacyjnemu Debian GNU/Linux (Potato, Wo-
ody, Sarge, Sid): http://asterix.wonder.pl/, w tym artykuły: M. Klesiewicz Instala-
cja, konfiguracja i administrowanie serwera sieciowego, P. Krawczyk Filtrowanie
stateful-inspection w Linuksie i BSD, R. Litwiniec Snort, R. Litwiniec Skanowanie
poczty.
[18] Strona domowa programu MKS: http://www.mks.com.pl/
[19] Strona opisująca zagadnienia związane ze Snortem:
http://www.aba.krakow.pl/security/snort.html
[20] Strona domowa systemu Snort: http://www.snort.org/
[21] Strona omawiająca pokaz
ny zbiór dystrybucji Linuksa:
http://www.distrowatch.com/
[22] Strona domowa systemu Debian: http://www.debian.org/, w tym wszelka dokumen-
tacja dotycząca samego systemu  packaging-manuals, J. F. Sanguino Pena Securing
Debian Manual.
[23] Strona z tłumaczeniami dokumentacji systemu Linux: http://lukasz.bromirski.net/,
w tym artykuły: Packet filtering in Linux 2.4, NAT in Linux 2.4, ipfilter HOWTO.
[24] Centrum bezpieczeństwa systemu Linux: http://www.linuxsecurity.com/, w tym ar-
tykuł O. Andreasson IPTables Tutorial.
[25] Strona z różnymi słownikami: http://slowniki.onet.pl  słownik języka polskiego.
[26] Polska wikipedia: http://pl.wikipedia.pl/
[27] Strona domowa maszyny wirtualnej VMware: http://www.vmware.com/