Gdy uruchamiamy linuksową stację roboczą i zamierzamy łączyć się z Internetem, musimy podjąć prawie takie same środki ostrożności jak administrator serwera. Wybór dystrybucji jest ważny, bo przesądza z jakimi programami przyjdzie nam pracować i w jaki sposób będziemy wykonywać niektóre bardziej specyficzne zadania - nie powinien więc być pochopny. W tym artykule czytelnicy zapoznają się z możliwościami i specyfiką tylko jednej dystrybucji Linuksa, Debianem. Na pewno jednak dużą część poznanej tutaj wiedzy da się zastosować także w innych -Red Hat, Slackware czy S.u.S.E.. Ponieważ źródła większości opisywanych programów są dostępne na popularnych serwisach FTP (adresy na końcu artykułu), nic nie stoi na przeszkodzie, aby wykorzystać omawiane rozwiązania we własnej dystrybucji. Wszelkie uwagi odnośnie treści artykułu oraz ewentualnych błędów lub niedomówień są mile widziane.
Dystrybucja Debian GNU/Linux cieszy się sławą solidnej i stabilnej. "Sztywne" zależności pomiędzy wersjami poszczególnych pakietów zwiększają niezawodność systemu i sprawiają, że Debian sprawdza się idealnie nie tylko jako serwer, ale także jako stacja robocza dla bardziej wymagających użytkowników.
Niemniej jednak nawet ona nie jest wolna od usterek i wad. Wszystkie systemy operacyjne wymagają, oprócz prawidłowej instalacji i konfiguracji, również stałej opieki ze strony użytkownika i administratora. Dotyczy to szczególnie bezpieczeństwa, gdzie pomyłka czy niedopatrzenie mają nieraz tragiczne konsekwencje. Problem powstaje, gdy temat zabezpieczeń zupełnie nas nie interesuje i nie zajmujemy się nim zawodowo czy hobbystycznie - i nie zamierzamy zatem poświęcać mu więcej czasu niż to jest konieczne. Chcielibyśmy ograniczyć nasze "łatanie" do rzeczy niezbędnych i tych bardziej przydatnych, które postaram się tu opisać.
Nie łudźmy się, że raz zainstalowany system będzie wiecznie sprawny i tak samo bezpieczny. Wraz z upływem czasu odkrywane są nowe błędy w oprogramowaniu, naprawiane są stare - za kilka miesięcy nasz podłączony do Internetu komputer może być celem ataków ludzi z całego świata. Mówiąc bardziej brutalnie, poziom zabezpieczeń naszej stacji roboczej maleje z każdym dniem. Dlatego oprócz stosowania generalnych zasad właściwego użytkowania, należy co jakiś czas odwiedzić stronę http://www.debian.org - znajduje się tam specjalny dział poświęcony interesującemu nas zagadnieniu - lub inne strony o podobnej tematyce, wymienione na końcu artykułu. Możemy tam zasięgnąć informacji o ewentualnych odkrytych lukach oraz o aktualnych wersjach pakietów nie posiadających usterek. Często jednak na raporty trzeba czekać tygodniami a nawet miesiącami. Wiele nieprawidłowości w działaniu programów jest znanych tylko wąskiej grupie ludzi, którzy utrzymują je w tajemnicy ze względu na potencjalne korzyści, jakie mogą dzięki temu osiągnąć. Co wtedy robić? Prędzej czy później "dziura" zostanie odkryta, a wiadomość o tym znajdzie się na którejś z popularnych list dotyczących bezpieczeństwa (a później - jeśli program którego dotyczy jest częścią tej dystrybucji - na stronie Debiana), jednak już wtedy może być za późno. Prawdopodobieństwo że staniemy się wcześniej celem ataku jest nikłe, niemniej jednak trzeba się z taką możliwością liczyć. Idealnym wyjściem byłoby stałe monitorowanie jednej lub kilku list dyskusyjnych (może to być bugtraq lub dowolna inna - adresy zostały podane na końcu artykułu) - ostrzeżenia pojawiają się tu średnio 7 dni wcześniej niż na "oficjalnej" stronie Debian GNU/Linux.
W chwili pisania artykułu aktualną stabilną wersją Debiana była wersja oznaczona numerem 2.2, znana także pod nazwą Potato. Wersja niestabilna została nazwana Woody. Oprócz tego część z omawianych bardziej szczegółowo zagadnień można odnieść do dystrybucji Corel Linux, także opartej na pakietach deb (choć przeznaczonej raczej dla mniej doświadczonych użytkowników) oraz komercyjnego Storm Linux. Tekst został jednak stworzony głównie z myślą o Debianie 2.2 (a także wcześniejszych 2.1 Slink i 2.0 Hamm). Duża liczba pakietów skłania raczej do wybrania jednego z kilku ich "zestawów" i tak też robi większość użytkowników. Później możemy dostosować system do swoich potrzeb instalując interesujące nas programy lub usuwając zbędne. Podstawowa konfiguracja odbywa się również podczas instalacji. Gdy już szczęśliwie przebrniemy przez te wszystkie zawiłości, ustawimy hasło superużytkownika (czyli roota) i zainstalujemy niezbędne programy, możemy zacząć przekształcanie naszego Linuksa w "bezpieczną stację roboczą".
Poniżej przedstawiono wybrane luki obecne w wersjach dystrybucji Debian GNU/Linux od 1.3 do 2.2 poprzez stabilne wersje poprawkowe rc2, rc5 itp.
Wszystkie wymienione luki w bezpieczeństwie zostały załatane w wersji 2.2 systemu. Oczywiście, są to jedynie dość znane przykłady - najbardziej aktualnych informacji należy szukać na listach dyskusyjnych i stronach Debiana.
Gdy nie ma potrzeby wykorzystywania jakiejś usługi, najlepiej uniemożliwić do niej dostęp. Na przykład, gdy nie mamy zamiaru udostępniać innym informacji o zalogowanych użytkownikach oraz kontach w systemie, należy zrezygnować z uruchamiania demona fingerd. Także większość usług typu RPC (Remote Procedure Call) nie jest przydatna na komputerze domowym.
Obsługą dużej części demonów internetowych w systemach uniksowych zajmuje się program inetd. Na wydruku 1 przedstawiono fragment przykładowego pliku konfiguracyjnego (/etc/inetd.conf) tego demona.
Gdy nie chcemy korzystać z danego programu, należy wiersz zawierający jego wywołanie opatrzyć znakiem komentarza. W przypadku programu finger wiersz ten będzie wyglądał następująco:
\#finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd
Następnie zapisujemy zmiany i restartujemy demona inetd poleceniem killall -HUP inetd. Od tej chwili połączenie z fingerd (port 79) będzie niemożliwe.
Zaleca się blokowanie wszystkiego, z czego nie zamierzamy korzystać. Zakładając, że mamy dostęp do Internetu przez łącze komutowane i nie zamierzamy uruchamiać żadnych serwisów, zostawiamy tylko: ftp (serwer plików - kiedy zamierzamy je czasami komuś udostępnić), smtp (serwer poczty wychodzącej - gdy zamierzamy wysyłać pocztę), ident (część serwerów ftp oraz IRC wymaga identyfikacji użytkownika nawiązującego połączenie). Oczywiście, tylko od nas zależy co chcemy zostawić, a co nie. Pełny spis usług i odpowiadających im portów znajduje się w pliku /etc/services.
Gdy chcemy umożliwić zdalnym użytkownikom dostęp do powłoki, nie musimy używać do tego celu programów telnet, rsh lub rlogin. Co więcej, nie jest to wskazane - programy te nie obsługują szyfrowania transmisji i każda osoba dysponująca przywilejami superużytkownika na komputerze, przez który przechodzą pakiety kierowane do naszego Linuksa może poznać niezakodowane hasło, a nawet przebieg całej sesji. Program Secure Shell umożliwia skorzystanie ze specjalnego protokołu zapewniającego szyfrowany algorytmem RSA kanał komunikacyjny. Mechanizm działania SSH to temat na osobny artykuł, jednak w skrócie można powiedzieć że identyfikacja użytkownika opiera się na sprawdzaniu wygenerowanych wcześniej kluczy publicznych (mogą mieć one długość od 512 bitów wzwyż) przesyłanych do innych uczestników transmisji. Służą one do kodowania danych; do dekodowania służą klucze prywatne. Cała transmisja jest szyfrowana kluczem o długości 256 bitów.
W Debianie 2.2 pakiety z programem ssh(d) znajdują się w dziale non-US. Oznacza to, że jest to oprogramowanie dodatkowe, nie będące częścią dystrybucji, a jednocześnie spełniające kryteria produktów objętych specjalnymi przepisami eksportowymi Stanów Zjednoczonych (algorytm ma mniejszą długość niż w wersji przeznaczonej na rynek amerykański - obecnie wspomniane przepisy ulegają zmianie). Mamy do dyspozycji zarówno wersję pierwszą (pakiet ssh-nonfree_1.2.27-4.deb - wersja bardziej znana i szerzej stosowana), jak i drugą (ssh2_2.0.13-4), której wymagają niektóre windowsowe klienty ssh. Ich darmowy odpowiednik (obie wcześniej wspomniane wersje zamieszczone są także w dziale non-free) to tzw. OpenSSH (wywodzący się z systemu OpenBSD) - zaleca się używanie właśnie tej odmiany, ponieważ ma ona opinię programu dość bezpiecznego, co w przypadku aplikacji tego rodzaju nie jest bez znaczenia. Pakiet to ssh_1.2.1pre24-1.deb (non-US/main).
Omówmy pokrótce zasadę działania narzędzia. W momencie instalacji właściwego pakietu generowana jest para kluczy identyfikujących nasz komputer (ssh_host_key - klucz prywatny oraz ssh_host_key.pub - klucz publiczny), która następnie zostaje zapisana w katalogu /etc/ssh. Tam również znajduje się plik konfiguracyjny klienta (ssh_config) i demona (sshd_config). Oprócz tego, w katalogu /etc/init.d tworzone są skrypty startowe uruchamiające sshd (secure shell daemon). Dzieje się to również po udanej instalacji.
Klienta ssh uruchamiamy poleceniem:
[tm:@ ~]$ ssh -l login host.pl
Gdzie login jest nazwą konta, a host.pl adresem komputera na który chcemy się zalogować. Potem już tylko musimy wpisać nasze hasło.
Gdy chcemy połączyć się z innym komputerem bez podawania hasła, musimy utworzyć programem ssh-keygen oba wymagane klucze. Wybieramy ich długość oraz hasło zabezpieczające klucz prywatny. Domyślnie są one umieszczane w katalogu $HOME/.ssh jako identity i identity.pub. Następnie przenosimy nasz klucz publiczny (z pliku ~/.ssh/identity.pub) do pliku $HOME/.ssh/authorized_keys na innym serwerze. Możemy to zrobić poleceniem cat identity.pub >> authorized_keys. Od teraz możemy logować się na nasze konto na tym serwerze bez podawania hasła.
Klientem programu Secure Shell można zalogować się na konto root, nawet jeśli nasz terminal nie jest wymieniony w pliku /etc/securetty. Nie można tego zrobić korzystając na przykład ze zwykłego telnetu.
Po udanej instalacji serwera możemy zablokować dostęp do usług telnet, rlogin i rsh tak, jak zostało to opisane w poprzednim rozdziale. Secure Shell obsługuje jeszcze jeden bardzo przydatny mechanizm. Jest nim tzw. przekazywanie portów (ang. port forwarding). Polega ono na łączeniu portów lokalnej stacji roboczej z portami dowolnie wybranej internetowej maszyny. Gdy chcemy połączyć port_zdalny serwera host.pl z portem port_lokalny naszego komputera, wpisujemy: [root]# ssh -L port_lokalny:host.pl:port_zdalny localhost Po wpisaniu hasła i rozpoczęciu sesji wszystkie połączenia na port_lokalny naszej maszyny będą przekazywane na port_zdalny host.pl. Równoważne polecenie to: [root]# ssh -R port_zdalny:host.pl:port_lokalny localhost To udogodnienie można wykorzystać do obsługi usług, które standardowo nie zapewniają możliwości szyfrowania transmisji (takich jak pop3). Dzięki temu nie będziemy przesyłać naszych haseł czystym tekstem przez całą drogę do zdalnego serwera. Do przekazywania portów o numerach mniejszych od 1024 potrzebujemy przywilejów superużytkownika. W przypadku innych możemy to robić jako zwykły użytkownik.[root]# dpkg -i libssl09_0.9.4-4.deb [root]# dpkg -i openssl_0.9.4-4.deb [root]# dpkg -i ssleay_0.9.4-4.debMusimy usunąć stare wersje telnet i telnetd:
[root]# dpkg --purge telnet [root]# dpkg --purge telnetdTeraz możemy przystąpić do instalacji programu:
[root]# dpkg -i telnet-ssl_0.14.9-1.deb [root]# dpkg -i telnetd-ssl_0.14.9-1.deb [root]# dpkg -i ssltelnet_0.14.9-1.debW tym momencie zamieniane są odpowiednie pliki. Nasz telnet jest teraz wyposażony w nowe funkcje - szczegółowe ich omówienie można znaleźć na stronie podręcznikowej (man 1 telnet lub man 8 telnetd).
Zanim ktoś zdecyduje się na włamanie do danego systemu komputerowego, zwykle stara się zebrać o nim jak najwięcej informacji. Jedną z metod "rozpoznania celu" jest skanowanie portów. Oczywiście, nie istnieje żaden sposób zabezpieczenia się przed próbami takiego działania - można je tylko wykryć i ewentualnie odpowiednio na nie reagować. Standardowo informacje o połączeniach na porty naszej maszyny przechwytuje demon syslogd i przesyła je w odpowiednie miejsce (patrz Syslogd - standartowa kontrola pracy systemu). Jednak tym sposobem dowiemy się tylko o najprymitywniejszych przypadkach skanowania portów - zwykłych pełnych połączeniach TCP z trzystopniowym potwierdzaniem (ang. three-way handshake). Istnieją o wiele bardziej wyrafinowane metody, nie są one jednak niewykrywalne, jak sądzono jeszcze jakiś czas temu. W rozpoznaniu ich pomoże nam pakiet iplogger (w wersji 2.2 to iplogger_1.1-7.deb). Zawiera dwa demony - tcplogd oraz icmplogd. Pamiętają one wszystkie połączenia przychodzące TCP oraz pakiety ICMP wysłane do naszego komputera i standardowo przekazują zawiadomienia o nich do syslogd jako daemon.notice. W pliku /etc/iplogger.conf możemy zdefiniować, czego używać do zapisu raportów oraz jakie pakiety rejestrować. Skrypty startowe obu demonów instalują się automatycznie w katalogu /etc/init.d.
Nawet jeśli jesteśmy bardzo pewni naszych zabezpieczeń, powinniśmy być przygotowani na najgorsze. Po włamaniu kluczową sprawą, oprócz załatania luki i wymiany haseł jest ustalenie, które pliki zostały zmienione. Zapewnienie spójności systemu to jedno z podstawowych zadań administratora. Ręczne sprawdzenie sum kontrolnych oraz dat powstania i modyfikacji plików może być dość kłopotliwe (sumę kontrolną MD5 danego pliku możemy utworzyć poleceniem md5sum plik). Dlatego między innymi powstał pakiet tripwire (ostatnia wersja tripwire_1.2-16.1.deb), który powiadomi nas o każdej niezgodności zachodzącej miedzy informacjami zapisanymi w bazie a aktualnym stanem. Po instalacji w pliku konfiguracyjnym /etc/tripwire/tw.config możemy określić co i jak ma być sprawdzane. Poleceniem tripwire -initialize generujemy listę, z którą będziemy później porównywać wyniki następnych sprawdzeń (program umieszcza ją jako aktualny_katalog_roboczy/databases/tw_db.nazwa.hosta, później należy ją skopiować do katalogu /usr/lib/tripwire/databases). W katalogu /etc/cron.weekly jest też umieszczany skrypt tripwire - jeśli nie odpowiada nam cotygodniowa kontrola możemy go przenieść np. do /etc/cron.monthly - wtedy cała operacja będzie wykonywana co miesiąc.
Jeśli wykonywalny plik ma ustawiony bit SUID, oznacza to że zawsze jest uruchamiany z przywilejami użytkownika, który jest jego właścicielem. Podobnie jest z bitem SGID - ale wtedy to grupa, do której należy program przekazuje swoje uprawnienia. Nie trzeba wyjaśniać, dlaczego takie ustawienia powinny być nadawane tylko w najbardziej uzasadnionych przypadkach. Największe niebezpieczeństwo zachodzi wtedy, gdy właścicielem jest root (lub grupa root w przypadku programów SGID). Obecność takich programów możemy sprawdzić poleceniem:
[root]# find / -type f -user root -perm -04000 -lsOraz dla SGID:
[root]# find / -type f -user root -perm -02000 -ls
Lista powinna być monitorowana. Zaleca się usunięcie bitów SUID z programów /bin/mount i /bin/umount (chyba że chcemy montować inne systemy plików jako zwykły użytkownik), a gdy zainstalujemy ssh to także z /usr/bin/rcp (w zastępstwie mamy program scp - część pakietu ssh), /usr/bin/rlogin i /usr/bin/rsh. Usunięcie wspomnianego bitu z innych programów także jest możliwe (chodzi tu np. o /bin/ping i /usr/bin/traceroute), jednak dopiero po dokonaniu niezbędnych zmian w źródłach jądra systemu i jego rekompilacji. W przeciwnym razie programy nie będą działać poprawnie.
Alternatywną metodą zapanowania nad popularnymi "suidami" jest instalacja pakietu suidmanager_0.43.2.deb (Debian 2.2). Wtedy za pomocą poleceń suidregister i suidunregister lub bezpośrednich wpisów do pliku /etc/suid.conf kontrolujemy obecność tych potencjalnie niebezpiecznych programów w naszym systemie.
Więcej na ten temat można dowiedzieć się z artykułu Zabezpieczenia w popularnych dystrybucjach Linuksa, który ukazał się w numerze 1/99 LinuxPlus.
Nie zawsze możemy przewidzieć, kto będzie łączył się z naszym komputerem. Części "gości" chcielibyśmy odmówić dostępu do konkretnych usług, portów lub nawet całego systemu. Do takich celów służą (między innymi) specjalne programy zwane zaporami sieciowymi (ang. firewall). Są to w większości produkty komercyjne (choć istnieje kilka bardzo dobrych i darmowych), wymagające sporej wiedzy i umiejętności przy instalacji oraz stałego nadzoru. Nie będą na pewno przeznaczone dla domowego użytkownika. Odmianą zapór sieciowych są tak zwane filtry pakietów IP (ang. packet filter). Jeśli chodzi o Linuksa, mamy do dyspozycji ipfwadm (jądra systemu w wersjach 2.0.x) oraz ipchains (wersje 2.2.x). Wymagają one jednak modyfikacji i rekompilacji jądra systemu - trzeba włączyć wszystkie opcje umożliwiające obsługę zapór sieciowych, co znacznie zwiększy rozmiar jądra. Oprócz tego, określenie dużej ilości adresów "zaufanych" i "niezaufanych" może powodować później trudności w zrozumieniu sytuacji (przynajmniej dla patrzącego na te ustawienia niezbyt obytego z Uniksem administratora). Filtry IP to niewątpliwie narzędzie dla średnio zaawansowanych i doświadczonych użytkowników. Stosowanie ich na stacji roboczej co prawda nie jest wygodne, ale niewątpliwie możliwe. Więcej na temat kompilacji jądra i ustawianiu odpowiednich opcji w części Rekompilacja jądra.
Podstawową kontrolę połączeń z usługami obsługiwanymi przez demony uruchamiane za pośrednictwem programu inetd zapewnia program tcpd (tak zwany TCP Wrapper). Wpisując w /etc/inetd.conf przed ścieżką do danego demona /usr/sbin/tcpd (tcpd może być zainstalowane w dowolnym innym miejscu), poddajemy ten program kontroli. Kluczowe znaczenie mają tu pliki /etc/hosts.allow i /etc/hosts.deny (w Debianie stosowany jest do dziś ten format zapisu, w innych dystrybucjach może być używany wyłącznie plik /etc/hosts.deny). Gdy chcemy na przykład odblokować niektóre programy tylko dla konkretnych osób, do hosts.deny wpisujemy ALL: ALL, natomiast do hosts.allow intersujące nas adresy IP lub domeny oraz nazwy usług w formacie nazwa_uslugi: .domena.pl (lub nazwa_hosta) - tak jak jest to pokazane na wydruku 2. Natomiast odwrotna operacja wymaga wpisania ALL: ALL do /etc/hosts.allow, a poniższych reguł do /etc/hosts.deny (wydruk 3).
To tylko najprostsze przykłady. Bardziej szczegółowe informacje można znaleźć na stronie podręcznikowej tcpd(8) (man 8 tcpd).
Pakiet sysklogd oferuje nam dwa demony, których zadaniem jest rejestrowanie pracy systemu: klogd oraz syslogd. Pierwszy przechwytuje wiadomości wysyłane przez jądro, drugi natomiast operuje w przestrzeni użytkownika (user space) i monitoruje działanie programów systemowych (i nie tylko). To właśnie ten ostatni jest jednym z głównych filarów bezpieczeństwa - gdy będziemy wiedzieli co się "u nas" dzieje, będziemy też w stanie łatwiej zlokalizować przyczyny ewentualnych problemów.
Co, jak i gdzie rejestrować określamy w pliku konfiguracyjnym /etc/syslog.conf. Gdy wprowadzamy zmiany do już istniejących ustawień, musimy pamiętać o specjalnym formacie zapisu. Z grubsza można go przedstawić tak: <słowo kluczowe>.<priorytet> <miejsce logwania>
Słowo kluczowe opisuje podsystem, który będzie wysyłał wiadomości. Najważniejsze dopuszczalne wartości tego parametru to: auth, auth-priv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp oraz local0 aż do local7.
Priorytet określa znaczenie i rodzaj wiadomości. Możemy go zdefiniować jako (zaczynając od najmniej istotnych): debug, info, notice, warning, warn (to samo co warning), err, error (to samo co err), crit, alert, emerg, panic (to samo, co emerg).
Parametr miejsce logowania nie musi być koniecznie plikiem - może wskazywać urządzenie blokowe (konsolę lub nawet terminal wirtualny), nazwę innego komputera naszej sieci, nazwę użytkownika czy też nazwany potok(kolejkę).
We wszystkich trzech przypadkach dopuszcza się stosowanie znaku * , który oznacza odwołania do wszystkich typów i/lub priorytetów, a w przypadku miejsca logowania wysyłanie wiadomości na terminale zalogowanych użytkowników.
Kilka przykładów możliwych konfiguracji możemy zobaczyć na wydruku 4.
Od nas zależy, jakie ustawienia uznamy za najbardziej właściwe. Po każdej zmianie należy zrestartować demona poleceniem killall -HUP syslog. Warto poeksperymentować.
Powtórna kompilacja jądra nie jest absolutnie konieczna, ale staje się niezbędna gdy chcemy zwiększyć szybkość systemu lub gdy potrzebujemy nowych sterowników. Czasami nowe wersje jądra mają nowe, przydatne funkcje i nie powtarzają starych błędów. O całej operacji napisano wiele, więc nie powinna już nikomu sprawiać kłopotów. Generalną tendencją jest usuwanie wszystkiego, czego nie musimy używać oraz dodawanie tego, co będzie nam potrzebne. Dzięki rozsądnemu wyborowi i skompilowaniu niektórych sterowników jako modułów ładowalnych można znacznie "odchudzić" jądro i wydatnie przyspieszyć naszego Linuksa. Warto też zainteresować się niektórymi opcjami bezpośrednio dotyczącymi bezpieczeństwa, np. TCP syncookie support (jej włączenie zapobiega atakom typu syn-flood - zalewanie pakietami SYN) czy też Quota support (wkompilowanie jej w jądro pozwoli nam ustawić limity przestrzeni dyskowych w systemie plików dla określonych użytkowników za pomocą programu quota). Opcje pozwalające uruchomić zaporę sieciową zostały opisane w artykule Zabezpieczenia w popularnych dystrybucjach Linuksa z LinuxPlus 1/99 (Tabela 3).
Czasami chcielibyśmy dać komuś dostęp do wirtualnej konsoli, ale nie jesteśmy w stu procentach pewni czy ta osoba (przez przypadek lub umyślnie) nie zakłóci pracy naszego systemu. Aby odebrać jej możliwość wykonywania niepożądanych czynności, możemy zastosować kilka rozwiązań.
Najprościej jest użyć wbudowanego polecenia powłoki bash, ulimit. Za jego pomocą można ustawić m.in. maksymalny rozmiar plików, pamięć wirtualną, zużycie czasu procesora, największe rozmiary plików zrzutu pamięci (core), nieprzekraczalny limit otwartych na raz deskryptorów plików, maksymalną liczbę procesów jakie dany użytkownik może rozpocząć oraz maksymalny rozmiar zajmowanej pamięci. Wszystkie limity zobaczymy po wydaniu polecenia ulimit -a. Więcej informacji na temat ich ustawiania znajduje się na stronie podręcznikowej builtins(1) (część ulimit).
Ponieważ Debian do wersji 2.1 nie ma w pełni zaimplementowanego mechanizmu PAM (Pluggable Authentication Modules), nie możemy określać globalnych limitów bezpośrednio w pliku /etc/security/limits.conf (tak jak w Red Hacie, S.u.S.E., Mandrake, Calderze czy Debianie 2.2, które te funkcje posiadają). Jednak jeśli muszą dotyczyć one wszystkich użytkowników (także naszego), nic nie stoi na przeszkodzie aby ustawić je w plikach startowych powłoki. Globalnie takim plikiem jest /etc/profile (cały czas mówimy o bashu). Do tego pliku wpisujemy polecenie ulimit [opcja] [nasz limit] i od tej pory każdy uruchamiający powłokę będzie objęty takimi ograniczeniami (nawet jeśli w swoim katalogu domowym posiada plik .bash_profile, który wykonywany jest później). Raz ustawionych w powłoce limitów nie można "złagodzić". Każdy program (np. powłoka csh, w której odpowiednikiem ulimit jest polecenie limit) z niej uruchomiony dziedziczy wszystkie ustawienia.
Takie rozwiązanie ma jednak dużo wad. Najważniejszą jest brak możliwości wybrania użytkowników, których ograniczenia chcemy skonfigurować inaczej. Jeśli mamy zamiar zrobić coś takiego, możemy zastosować inną metodę polegającą na odpowiednim wpisie do pliku /etc/limits, z którego korzysta program login. Limity w tym wypadku możemy przyznawać TYLKO poszczególnym nazwom użytkowników. Więcej informacji o formacie i sposobie zapisu znajduje się na stronie podręcznikowej limits(5) oraz w komentarzach tego pliku.
Wróćmy teraz do Debiana 2.2. Tu już sytuacja wygląda dużo lepiej. Za przydzielanie i kontrolę zasobów odpowiedzialny jest wcześniej wspomniany zestaw bibliotek PAM. Szczegółowe ustawienia dotyczące takich narzędzi jak chfn, chsh, login, ppp, su i innych możemy obejrzeć w pliku /etc/pam.conf lub w katalogu /etc/pam.d (gdy ten drugi istnieje, zawartość pierwszego jest ignorowana). Zmiany w konfiguracji wprowadzamy poprzez edycję tych plików. W obszernym dokumencie Linux-PAM system administrators' guide jest napisane jak się do tego zabrać - po zainstalowaniu libpam-doc_0.72-3.deb (sekcja doc) dokument ten powinien się znajdować w katalogu /usr/share/doc/libpam-doc. Należy zastanowić się nad takimi opcjami jak maksymalna i minimalna długość hasła (passwd), dostęp do polecenia su tylko dla członków grupy root czy też ograniczenia w używaniu przez naszych użytkowników poleceń chfn i chsh. W połączeniu ze zmianami w /etc/login.defs (kolejny plik konfiguracyjny programu login - więcej szczegółów na stronie login.defs(5) ), to właściwie powinno nam wystarczyć.
Z /etc/pam.d/login związana jest jeszcze jedna ważna kwestia - omawiane wcześniej ograniczenia. Opcje włączamy poprzez usunięcie znaków komentarza z odpowiednich wpisów we wspomnianym pliku (ponieważ są opatrzone opisem, nie sądzę aby były problemy z ich znalezieniem).
Do wyboru są ograniczenia dostępu do programu login, praw innych grup, limity czasowe (np. czy w danym dniu o określonej godzinie użytkownik może korzystać z określonych usług), ustawienie odpowiednich zmiennych środowiskowych, a także najbardziej nas chyba interesujące limity zasobów. Konfiguracja poszczególnych działów jest pogrupowana tematycznie w katalogu /etc/security:
access.conf - dostęp do login: określamy użytkowników, adres źródłowy, rodzaj działania (+ - przyjęcie, - - odrzucenie);
group.conf - dostęp do grup: usługa, terminal, użytkownik, czas obowiązywania, grupa (lub grupy);
limits.conf - zasoby: użytkownik (może też być grupa), typ limitu (miękki lub twardy), rodzaj oraz wartość;
pam_env.conf - zmienne globalne: nazwa zmiennej, wartość domyślna, odwołanie do innej zmiennej (gdy jest ustawiona, jej wartość zostanie przyjęta; w przeciwnym razie ustawiona będzie wartość domyślna);
time.conf - ograniczenia czasowe: usługa, terminale, użytkownik, czas obowiązywania
W starszych Debianach (z zainstalowanym pakietem shadow) niepełnymi odpowiednikami są /etc/login.access, kilka opcji z /etc/login.defs oraz /etc/limits. Jednak PAM oferuje dużo większe możliwości - warto poeksperymentować.
Istnieje jeszcze kilka możliwości ustawiania ograniczeń powłoki. Stosunkowo najgorszą i wymagającą najwięcej zachodu jest tzw. restricted bash (strona podręcznika to rbash(1)). Prawidłowa konfiguracja tego narzędzia nastręcza sporo problemów, a i tak z powodu kilku przeoczeń (w większości przypadków chodzi o aplikacje, do których użytkownik miał mieć dostęp - czasami zaimplementowane w nich funkcje niweczą cały wysiłek administratora) może nie wystarczyć. Możliwość uruchomienia własnej powłoki bez ograniczeń, przegrywanie na konto i wykonywanie własnych programów to najczęściej spotykane rezultaty. Właściwym rozwiązaniem wydaje się odpowiednio ustawiana zmienna środowiskowa $PATH (uniemożliwienie dostępu do powłok i katalogu domowego) oraz montowanie partycji z katalogiem domowym użytkownika jako noexec (zapobieganie wykonaniu przegranej na konto powłoki) jednak jest to bardzo często czasochłonne, kłopotliwe i - co najważniejsze - niepewne. Istnieje wiele sposobów "wyprowadzenia w pole" rbasha i dlatego nie należy go stosować. W środowisku bardziej surowych ograniczeń (czyli takim, w którym moglibyśmy użyć rbasha) należy sięgnąć po tak zwane wirtualne systemy. Adresy, pod którymi można znaleźć oraz przykłady tego rodzaju programów, znajdują się na końcu artykułu.
Ogólne wzory bezpiecznego użytkowania systemu - polityka ograniczonego zaufania
W rękach lekkomyślnego i niedbałego administratora nawet najbezpieczniejszy system staje się dla włamywacza łatwym celem. Dlatego warto przyswoić sobie kilka nawyków, które w pewnych sytuacjach mogą nam "uratować życie" czyli zaoszczędzić czas i zdrowie, a nierzadko i zapisane na dysku cenne dane.
Przede wszystkim nie należy przyjmować, że każda osoba z którą rozmawiamy np. za pośrednictwem usługi IRC ma wobec nas całkowicie jasne zamiary. Zatem nie ogłaszajmy wszystkim szczegółowo ustawień naszego systemu, odrzucajmy prośby o wysłanie ważnych plików konfiguracyjnych, nie wykonujmy skompilowanych programów nieznanego pochodzenia (a już na pewno nie jako użytkownik root!), zastanówmy się dobrze jeśli chodzi o zakładanie kont nieznanym nam bliżej osobom - a jeśli już się na to zdecydujemy, należy ustawić tym użytkownikom odpowiednie ograniczenia (tak jak zostało to pokazane w poprzednim rozdziale). W codziennej pracy w Internecie i poza nim używajmy specjalnie stworzonego do tego celu konta. Zwykle zadania, które wykonujemy, nie wymagają najwyższych przywilejów. Superużytkownik powinien nam wyłącznie służyć do wprowadzania zmian w konfiguracji systemu - w żadnym wypadku do ściągania poczty, pisania na grupy dyskusyjne czy też "ircowania". Pamiętajmy o tym.
Bardzo ważne są hasła - nie trzeba chyba tłumaczyć, że powinny być takie, aby nie można było ich odgadnąć. W tym celu warto zainstalować pakiet pwgen (Debian 2.2 -wersja 1-15). Program służy do "losowego" tworzenia haseł - w wierszu poleceń podajemy jedynie ich maksymalną długość oraz określamy, czy mają się składać jedynie ze znaków alfanumerycznych (pwgen) czy też ze wszystkich znaków należących do "dolnej połowy" tablicy ASCII i dających się wydrukować (pwgen z opcją -s, czyli spwgen). Niestety, wspomniane narzędzie wymaga biblioteki libc6 i nie będzie działać na systemach w nią nie wyposażonych. Oczywiście, nawet gdy mamy (według nas) "silne" hasło, nie należy rezygnować z jego zmian. Zmiana hasła co pewien czas powinna również być nawykiem.
Nie udostępniajmy w pełni wszystkim zasobów naszego komputera tylko dlatego, że ktoś o to poprosi. Nie ustawiajmy na stałe niekontrolowanego dostępu do serwera X poleceniem xhost +. Niebezpieczeństwa takiego postępowania nie trzeba chyba nikomu tłumaczyć. Także lokalnie pewne usługi powinny być dostępne wyłącznie dla osób z określonych grup (np. dostęp do programu su, serwera X, pppd, czy innych systemów plików). W tym celu mamy już stworzone grupy audio, floppy, cdrom i inne. Jeśli potrzebujemy dostępu do jakichś przywilejów, po prostu dodajmy naszego użytkownika do odpowiedniej z grup. Pamiętajmy też, że nigdy nie możemy do końca ufać stworzonym zabezpieczeniom. Trzeba jednak postępować tak, aby ich pewność i skuteczność była jak największa.