Remove very outdated files

CVS version numbers

polish/international/Polish/bezpieczny_debian.wml: 1.4 -> 1.5(DEAD) 
polish/international/Polish/free.wml: 1.1 -> 1.2(DEAD) 
polish/international/Polish/index.wml: 1.16 -> 1.17 
polish/international/Polish/instalacja_potato.wml: 1.2 -> 1.3(DEAD) 
polish/international/Polish/manifest.wml: 1.1 -> 1.2(DEAD) 
polish/international/Polish/polaczenie_z_internetem.wml: 1.1 -> 1.2(DEAD) 
polish/international/Polish/system_pakietow.wml: 1.3 -> 1.4(DEAD) 
polish/international/Polish/wprowadzenie.wml: 1.1 -> 1.2(DEAD) 
polish/international/Polish/wstep_do_debiana.wml: 1.2 -> 1.3(DEAD)

1 files changed, 0 insertions, 720 deletions

diff --git a/polish/international/Polish/bezpieczny_debian.wml b/polish/international/Polish/bezpieczny_debian.wml
deleted file mode 100644
index 70e2b429b22..00000000000
--- a/polish/international/Polish/bezpieczny_debian.wml
+++ /dev/null
@@ -1,720 +0,0 @@
-#use wml::debian::template title="Debian GNU/Linux - bezpieczna stacja robocza" NOHEADER="yes"
-
-<h2>Debian GNU/Linux - bezpieczna stacja robocza</h2>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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ć.</p>
-
-<p>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.</p>
-
-<p>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ą".</p>
-
-<h3>Ważniejsze usterki systemu mogące prowadzić do naruszenia jego
-bezpieczeństwa</h3>
-
-<p>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.</p>
-
-<ul>
-<li>
-Demony bootpd i ftpd z pakietu netstd w wersjach starszych niż 3.07-2
-były podatne na atak przez przepełnienie bufora (Debian 1.3 / 2.0).
-Obecnie zostały już załatane.
-</li>
-<li>
-Demon finger o nazwie cfingerd nigdy nie cieszył się sławą
-bezpiecznego. Odkryto w nim dużo bardzo poważnych błędów (szczególnie w
-starszych wersjach). Dlatego też większość specjalistów zaleca
-korzystanie ze standartowego demona (fingerd) znajdującego się w
-pakiecie netstd.
-</li>
-
-<li>
-lincity - gra lincity w wersjach 1.03-2 i 1.09-1 (Debian 1.3.1),
-instalowana wraz z pakietem lincity-svga, zawiera błąd przepełnienia
-bufora mogący prowadzić do nieautoryzowanego dostępu do przywilejów
-superużytkownika. Późniejsze wersje są bezpieczne.
-</li>
-
-<li>
-mailx-8.1.1-9 i wcześniejsze - pozwala uzyskać intruzowi przywileje
-grupy mail.
-</li>
-
-<li>
-Program suidexec dostarczany razem z pakietem suidmanager (wersje
-wcześniejsze niż 0.19) pozwala na wykonanie każdemu użytkownikowi
-dowolnego programu z prawami roota, jeśli istnieje w systemie choć
-jeden skrypt powłoki z ustawionym bitem SUID.
-</li>
-
-<li>
-W bibliotece z pakietu ldso_1.9.2 (plik ld-linux.so.1.9.2) jest błąd
-pozwalający na uzyskanie przywilejów użytkownika root.
-</li>
-
-<li>
-Program lsof w wersji 4.04 i wcześniejszych pozwala na lokalne
-uzyskanie dostępu do uprawnień superużytkownika (zostało to naprawione
-w wersji 4.37).
-</li>
-
-<li>
-Pakiet super_3.11.6 i wcześniejsze także mają usterki mogące prowadzić
-do uzyskania nieautoryzowanego dostępu.
-</li>
-
-<li>
-Gra xsoldier (wersja 1:0.96.7 i wcześniejsze) jest domyślnie
-instalowana z bitem SUID i zawiera groźny błąd mogący prowadzić do
-uzyskania dostępu do całego systemu. Należy zainstalować nowszą wersję
-tego programu lub zdjąć wspomniany bit: chmod -s /usr/games/xsoldier.
-</li>
-
-<li>
-Demon ftp o nazwie wuftpd począwszy od wersji 2.4.2, poprzez BETA-15 do
-BETA-18, aż do 2.5.0 zawiera szereg błędów krytycznych dla
-bezpieczeństwa systemu. Należy zrezygnować z jego używania (istnieje
-pakiet netstd zawierający bezpieczniejszą alternatywę) lub zainstalować
-najnowszą możliwą wersję (w tej chwili 2.6.0).
-</li>
-
-<li>
-fsp - w Debianie 2.0 ten program tworzył nieautoryzowane konto o nazwie
-ftp. W wersji 2.71 pakietu błąd został naprawiony (jeśli jednak
-instalowaliśmy starsze wersje, po aktualizacji należy też skasować
-wspomniane konto).
-</li>
-
-<li>
-cfengine - w wersji 2.0 systemu program ten zawierał błąd pozwalający
-na naruszenia bezpieczeństwa. Został on naprawiony w wersji 1.4.9-3
-pakietu.
-</li>
-
-<li>
-W pakietach sendmail oraz sendmail-wide występuje usterka pozwalająca
-na zniszczenie zwykłemu użytkownikowi bazy aliasów pocztowych. Zostało
-to naprawione w wersji sendmail_8.9.3-3slink1.
-</li>
-
-<li>
-Wcześniejsze niż 3.1.5-0.1 pakiety zawierające aplikację htdig mają
-poważną usterkę mogącą prowadzić do uzyskania zdalnego dostępu do
-systemu.
-</li>
-
-<li>
-Demon lpr w wersjach wcześniejszych niż 0.48-0.slink1 pozwalał na
-zdalne uzyskanie przywilejów superużytkownika. Zamiast dalszego
-używania tego programu zaleca się korzystanie z narzędzi zawartych w
-pakiecie lprng.
-</li>
-
-<li>
-apcd - rozpowszechniany razem z Debianem 2.1 Slink jest podatny na atak
-wykorzystujący dowiązania symboliczne. Błąd został naprawiony w wersji
-0.6a.nr-4slink1 pakietu.
-</li>
-
-<li>
-Podobny atak można było przeprowadzić z powodu niedoskonałości programu
-make. Zostało to naprawione w wersji 3.77-5slink.
-</li>
-
-<li>
-Program nmh (wcześniejsze niż 0.27-0.28-pre8-4) może zostać wprowadzony
-w błąd przez odpowiednio spreparowane nagłówki MIME, co w konsekwencji
-może doprowadzić do wykonania kodu z prawami użytkownika root.
-</li>
-
-<li>
-mtr (starsze od0.28-1) domyślnie zainstalowany z bitem SUID,
-niewłaściwie zwalnia wykorzystywane przywileje, co może być przyczyną
-lokalnego zagrożenia.
-</li>
-</ul>
-
-<p>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.</p>
-
-<h3>Blokowanie dostępu do niepotrzebnych usług</h3>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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:
-
-<pre>
- \#finger        stream  tcp     nowait  nobody  /usr/sbin/tcpd  /usr/sbin/in.fingerd
-</pre>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h3>Instalacja i konfiguracja programu Secure Shell (SSH)</h3>
-
-<p>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.</p>
-
-<p>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).</p>
-
-<p>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.</p>
-
-<p>Klienta ssh uruchamiamy poleceniem: 
-<pre>
-[tm:@ ~]$ ssh -l login host.pl 
-</pre>
-
-<p>Gdzie login jest nazwą konta, a host.pl adresem komputera na który chcemy
-się zalogować. Potem już tylko musimy wpisać nasze hasło.</p>
-
-<p>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
-<tt>cat identity.pub &gt;&gt; authorized_keys</tt>. Od teraz możemy logować się na nasze
-konto na tym serwerze bez podawania hasła.</p>
-
-<p>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.</p>
-
-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.
-
-<h3>Program SSLtelnet</h3>
-
-Gdy z jakichś powodów musimy używać telnetu (np. osoby, którym
-chcielibyśmy udostępnić powłokę używają systemów nie-uniksowych i nie
-posiadają klientów ssh - dla MS Windows 9x istnieją odpowiednie programy,
-natomiast np. dla MS-DOS niestety nie), najlepiej byłoby, gdyby
-obsługiwał on możliwość szyfrowania transmisji. Pomocą będzie nam tutaj
-służyło narzędzie telnet(d)-ssl. Program składa się z klienta oraz demona
-i ma za zadanie zastąpić standartowy telnet. Obsługuje technologię SSL
-(Secure Socket Layer) i dzięki temu może nawiązać bezpieczne połączenie,
-gdy druga strona także ma zaimplementowaną tę funkcję. W przeciwnym razie
-używany jest kanał niezakodowany (tak jak w "zwykłym" telnecie). Dzięki
-temu mamy zarówno możliwość szyfrowania, jak i łączność z innymi, nie
-posiadającymi klientów ssh osobami.
-
-Aby zainstalować SSLtelnet(d), potrzebujemy odpowiednich bibliotek.
-Znajdują się one w oddzielnym pakietach (dział non-US, numery wersji
-takie jak w Debianie 2.2):
-<pre>
-[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.deb 
-</pre>
-Musimy usunąć stare wersje telnet i telnetd: 
-<pre>
-[root]# dpkg --purge telnet 
-[root]# dpkg --purge telnetd 
-</pre>
-Teraz możemy przystąpić do instalacji programu: 
-<pre>
-[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.deb 
-</pre>
-W 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).
-
-<h3>Icmplogd i Tcplogd - programy logujące próby nawiązywania
-połączeń</h3>
-
-<p>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.</p>
-
-<h3>Tripwire - sprawdzanie sum kontrolnych plików</h3>
-<p>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.</p>
-
-<h3>Programy SUID i SGID</h3>
-<p>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:</p>
-
-<pre>
-[root]# find / -type f -user root -perm -04000 -ls 
-</pre>
-
-Oraz dla SGID: 
-
-<pre>
-[root]# find / -type f -user root -perm -02000 -ls 
-</pre>
-
-<p>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.
-
-<p>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.
-
-<p>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.
-
-<h3>Filtrowanie połączeń przychodzących - program tcpd</h3>
-
-<p>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.
-
-<p>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).
-
-<p>To tylko najprostsze przykłady. Bardziej szczegółowe informacje można
-znaleźć na stronie podręcznikowej tcpd(8) (man 8 tcpd).
-
-<h3>Syslogd -kontrola pracy systemu</h3>
-
-<p>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.
-
-<p>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:
-
-&lt;słowo kluczowe&gt;.&lt;priorytet&gt;      &lt;miejsce logwania&gt;
-
-<p>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.
-
-<p>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).
-
-<p>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ę).
-
-<p>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.
-
-<p>Kilka przykładów możliwych konfiguracji możemy zobaczyć na wydruku 4.
-
-<p>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ć.
-  
-<h3>Rekompilacja jądra systemu</h3>
-
-<p>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).
-
-
-<h3>Ustawianie ograniczeń powłoki</h3>
-
-<p>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ń.
-
-<p>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).
-
-<p>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.
-
-<p>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.
-
-<p>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ć.
-
-<p>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).
-
-<p>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:
-
-
-<p>access.conf - dostęp do login: określamy użytkowników, adres źródłowy,
-rodzaj działania (+ - przyjęcie, - - odrzucenie);
-
-<p>group.conf - dostęp do grup: usługa, terminal, użytkownik, czas
-obowiązywania, grupa (lub grupy);
-
-<p>limits.conf - zasoby: użytkownik (może też być grupa), typ limitu (miękki
-lub twardy), rodzaj oraz wartość;
-
-<p>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);
-
-<p>time.conf - ograniczenia czasowe: usługa, terminale, użytkownik, czas
-obowiązywania
-
-<p>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ć.
-
-<p>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.
-
-<p>Ogólne wzory bezpiecznego użytkowania systemu - polityka ograniczonego
-zaufania
-
-<p>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.
-
-<p>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.
-
-<p>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.
-
-<p>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.