added an article on Debian security from Linux+

CVS version numbers

polish/international/Polish/bezpieczny_debian.wml: INITIAL -> 1.1 
polish/international/Polish/index.wml: 1.2 -> 1.3

2 files changed, 727 insertions, 2 deletions

diff --git a/polish/international/Polish/bezpieczny_debian.wml b/polish/international/Polish/bezpieczny_debian.wml
new file mode 100644
index 00000000000..8027a5cc006
--- /dev/null
+++ b/polish/international/Polish/bezpieczny_debian.wml
@@ -0,0 +1,720 @@
+#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;      &ltmiejsce 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.
diff --git a/polish/international/Polish/index.wml b/polish/international/Polish/index.wml
index b524b1a64b7..6336edc8f5d 100644
--- a/polish/international/Polish/index.wml
+++ b/polish/international/Polish/index.wml
@@ -7,8 +7,13 @@
 poświęcony w całości Debianowi. Zawiera on kilka ciekawych artykułów, a
 co najważniejsze - aż siedem płytek CD z pakietami .deb</li>
 
-<li>Jeśli masz jakiś pomysł na to, co mogłoby się znaleźć na tej stronie,
-skontaktuj się ze mną (Marcin Owsiany
+<li>Oto jeden z artukułów z tego numeru: <a
+href="bezpieczny_debian.pl.html">``Debian GNU/Linux - bezpieczna stacja
+robocza''</a>, udostępniony dzięki uprzejmości redaktorów. (Wkrótce
+więcej tekstów.)</li>
+
+<li>Jeśli masz jeszcze jakiś pomysł na to, co mogłoby się znaleźć na tej
+stronie, skontaktuj się ze mną (Marcin Owsiany
 &lt;porridge@debian.org&gt;)</li>
 
 </ul>