diff options
author | Konrad Bielak <vandut> | 2005-12-01 12:07:40 +0000 |
---|---|---|
committer | Konrad Bielak <vandut> | 2005-12-01 12:07:40 +0000 |
commit | f740bf5fbb7a921d29031185533f9e62e69f328d (patch) | |
tree | 0b614576412389628c0c3ee965f6af60c18039f8 /polish/international/Polish/bezpieczny_debian.wml | |
parent | 1b72ded16f8480cd690a7578538d5fe2e7f3b0a1 (diff) |
New update.current
CVS version numbers
polish/.wmlrc: 1.4 -> 1.5
polish/contact.wml: 1.31 -> 1.32
polish/donations.wml: 1.35 -> 1.36
polish/social_contract.wml: 1.8 -> 1.9
polish/support.wml: 1.29 -> 1.30
polish/Bugs/Developer.wml: 1.23 -> 1.24
polish/Bugs/server-control.wml: 1.10 -> 1.11
polish/Bugs/server-refcard.wml: 1.9 -> 1.10
polish/Bugs/server-request.wml: 1.7 -> 1.8
polish/CD/index.wml: 1.19 -> 1.20
polish/CD/faq/index.wml: 1.30 -> 1.31
polish/CD/http-ftp/index.wml: 1.10 -> 1.11
polish/CD/mirroring/rsync-mirrors.wml: 1.2 -> 1.3
polish/CD/vendors/index.wml: 1.24 -> 1.25
polish/CD/vendors/legal.wml: 1.8 -> 1.9
polish/MailingLists/debian-announce.wml: 1.4 -> 1.5
polish/MailingLists/disclaimer.wml: 1.2 -> 1.3
polish/News/2002/20021216.wml: 1.4 -> 1.5
polish/News/2003/20030119.wml: 1.3 -> 1.4
polish/News/2003/20030127.wml: 1.3 -> 1.4
polish/News/2003/20030811.wml: 1.5 -> 1.6
polish/News/2003/20031005.wml: 1.4 -> 1.5
polish/News/2003/20031121a.wml: 1.5 -> 1.6
polish/News/2004/20040406.wml: 1.3 -> 1.4
polish/News/2004/20040515.wml: 1.1 -> 1.2
polish/News/2004/20040524.wml: 1.4 -> 1.5
polish/News/2004/20041026.wml: 1.2 -> 1.3
polish/News/weekly/contributing.wml: 1.10 -> 1.11
polish/News/weekly/index.wml: 1.8 -> 1.9
polish/News/weekly/2004/05/index.wml: 1.3 -> 1.4
polish/News/weekly/2004/10/index.wml: 1.6 -> 1.7
polish/News/weekly/2004/11/index.wml: 1.2 -> 1.3
polish/News/weekly/2004/20/index.wml: 1.2 -> 1.3
polish/News/weekly/2004/23/index.wml: 1.5 -> 1.6
polish/News/weekly/2004/27/index.wml: 1.2 -> 1.3
polish/News/weekly/2004/32/index.wml: 1.2 -> 1.3
polish/News/weekly/2004/33/index.wml: 1.3 -> 1.4
polish/News/weekly/2004/34/index.wml: 1.3 -> 1.4
polish/News/weekly/2004/35/index.wml: 1.4 -> 1.5
polish/News/weekly/2004/36/index.wml: 1.6 -> 1.7
polish/News/weekly/2004/37/index.wml: 1.2 -> 1.3
polish/banners/index.wml: 1.2 -> 1.3
polish/consultants/757_technologies.wml: 1.3 -> 1.4
polish/consultants/aerasec.wml: 1.3 -> 1.4
polish/consultants/alex_r.wml: 1.2 -> 1.3
polish/consultants/altoros.wml: 1.3 -> 1.4
polish/consultants/andreas_o.wml: 1.2 -> 1.3
polish/consultants/andreu_i.wml: 1.2 -> 1.3
polish/consultants/andrew_f.wml: 1.2 -> 1.3
polish/consultants/anthony_p.wml: 1.3 -> 1.4
polish/consultants/avalonix.wml: 1.2 -> 1.3
polish/consultants/baltazar_q.wml: 1.2 -> 1.3
polish/consultants/bao_h.wml: 1.2 -> 1.3
polish/consultants/beeznest.wml: 1.2 -> 1.3
polish/consultants/ben_b.wml: 1.2 -> 1.3
polish/consultants/benjamin_s.wml: 1.2 -> 1.3
polish/consultants/blue_orb.wml: 1.2 -> 1.3
polish/consultants/brickred_technologies.wml: 1.2 -> 1.3
polish/consultants/bruce_p.wml: 1.2 -> 1.3
polish/consultants/bryan_b.wml: 1.2 -> 1.3
polish/consultants/carlos_hg.wml: 1.3 -> 1.4
polish/consultants/catalyst.wml: 1.3 -> 1.4
polish/consultants/filippo_giunchedi.wml: 1.2 -> 1.3
polish/consultants/heureka.wml: 1.2 -> 1.3
polish/consultants/iceguard.wml: 1.2 -> 1.3
polish/consultants/john_b.wml: 1.2 -> 1.3
polish/consultants/lawrence_c.wml: 1.2 -> 1.3
polish/consultants/linunet.wml: 1.2 -> 1.3
polish/consultants/michael_b.wml: 1.2 -> 1.3
polish/consultants/mohawk_software.wml: 1.2 -> 1.3
polish/consultants/nils_r.wml: 1.3 -> 1.4
polish/consultants/rafez_n.wml: 1.2 -> 1.3
polish/consultants/sosa.wml: 1.2 -> 1.3
polish/consultants/stuart_t.wml: 1.2 -> 1.3
polish/consultants/turo_technology.wml: 1.2 -> 1.3
polish/consultants/ultreia.wml: 1.3 -> 1.4
polish/consultants/vivek_k.wml: 1.2 -> 1.3
polish/devel/index.wml: 1.26 -> 1.27
polish/devel/debian-desktop/index.wml: 1.7 -> 1.8
polish/devel/debian-installer/archive.wml: 1.3 -> 1.4
polish/devel/debian-installer/errata.wml: 1.9 -> 1.10
polish/devel/debian-installer/gtk-frontend.wml: 1.8 -> 1.9
polish/devel/debian-installer/ports-status.wml: 1.19 -> 1.20
polish/devel/debian-installer/svn.wml: 1.5 -> 1.6
polish/devel/debian-installer/News/2004/8.wml: 1.3 -> 1.4
polish/devel/debian-installer/News/2004/9.wml: 1.3 -> 1.4
polish/devel/debian-installer/News/2004/99.wml: 1.2 -> 1.3
polish/devel/debian-med/index.wml: 1.6 -> 1.7
polish/devel/debian-med/practice.wml: 1.3 -> 1.4
polish/devel/join/index.wml: 1.2 -> 1.3
polish/devel/join/newmaint.wml: 1.2 -> 1.3
polish/devel/join/nm-step1.wml: 1.3 -> 1.4
polish/devel/join/nm-step2.wml: INITIAL -> 1.1
polish/devel/website/index.wml: 1.2 -> 1.3
polish/devel/wnpp/index.wml: 1.12 -> 1.13
polish/devel/wnpp/wnpp.wml: 1.3 -> 1.4
polish/devel/wnpp/work_needing.wml: 1.2 -> 1.3
polish/distrib/cd.wml: 1.5 -> 1.6
polish/distrib/ftplist.wml: 1.20 -> 1.21
polish/doc/books.wml: 1.17 -> 1.18
polish/doc/cvs.wml: 1.7 -> 1.8
polish/doc/ddp.wml: 1.3 -> 1.4
polish/doc/devel-manuals.wml: 1.7 -> 1.8
polish/doc/docpolicy.wml: 1.6 -> 1.7
polish/doc/misc-manuals.wml: 1.5 -> 1.6
polish/doc/todo.wml: 1.3 -> 1.4
polish/doc/topics.wml: 1.4 -> 1.5
polish/doc/user-manuals.wml: 1.15 -> 1.16
polish/international/index.wml: 1.17 -> 1.18
polish/international/Polish/bezpieczny_debian.wml: 1.5 -> 1.6
polish/international/Polish/free.wml: 1.2 -> 1.3
polish/international/Polish/index.wml: 1.17 -> 1.18
polish/international/Polish/instalacja_potato.wml: 1.3 -> 1.4
polish/international/Polish/manifest.wml: 1.2 -> 1.3
polish/international/Polish/polaczenie_z_internetem.wml: 1.2 -> 1.3
polish/international/Polish/system_pakietow.wml: 1.4 -> 1.5
polish/international/Polish/wprowadzenie.wml: 1.2 -> 1.3
polish/international/Polish/wstep_do_debiana.wml: 1.3 -> 1.4
polish/intro/about.wml: 1.39 -> 1.40
polish/intro/cn.wml: 1.38 -> 1.39
polish/intro/search.wml: 1.3 -> 1.4
polish/intro/why_debian.wml: 1.13 -> 1.14
polish/legal/cryptoinmain.wml: INITIAL -> 1.1
polish/legal/index.wml: INITIAL -> 1.1
polish/legal/notificationforarchive.wml: INITIAL -> 1.1
polish/legal/notificationfornewpackages.wml: INITIAL -> 1.1
polish/mirror/official_sponsors.wml: 1.4 -> 1.5
polish/mirror/sponsors.wml: 1.2 -> 1.3
polish/mirror/submit.wml: 1.3 -> 1.4
polish/misc/awards.wml: 1.5 -> 1.6
polish/misc/memberships.wml: 1.4 -> 1.5
polish/partners/partners-form.wml: 1.4 -> 1.5
polish/po/bugs.pl.po: 1.12 -> 1.13
polish/po/countries.pl.po: 1.11 -> 1.12
polish/po/distrib.pl.po: 1.6 -> 1.7
polish/po/doc.pl.po: 1.6 -> 1.7
polish/po/langs.pl.po: 1.15 -> 1.16
polish/po/organization.pl.po: 1.13 -> 1.14
polish/po/others.pl.po: 1.20 -> 1.21
polish/po/ports.pl.po: 1.6 -> 1.7
polish/po/security.pl.po: 1.9 -> 1.10
polish/po/templates.pl.po: 1.19 -> 1.20
polish/ports/amd64/index.wml: 1.9 -> 1.10
polish/ports/freebsd/bsd-libc-based.wml: INITIAL -> 1.1
polish/ports/i386/index.wml: 1.3 -> 1.4
polish/ports/netbsd/news.wml: 1.3 -> 1.4
polish/releases/index.wml: 1.28 -> 1.29
polish/releases/potato/index.wml: 1.29 -> 1.30
polish/releases/sarge/index.wml: 1.14 -> 1.15
polish/releases/slink/index.wml: 1.19 -> 1.20
polish/releases/woody/errata.wml: 1.7 -> 1.8
polish/releases/woody/installmanual.wml: 1.8 -> 1.9
polish/releases/woody/releasenotes.wml: 1.3 -> 1.4
polish/security/crossreferences.wml: INITIAL -> 1.1
polish/security/cve-compatibility.wml: INITIAL -> 1.1
polish/security/index.wml: 1.30 -> 1.31
polish/security/2003/dsa-231.wml: 1.3 -> 1.4
polish/security/2003/dsa-233.wml: 1.3 -> 1.4
polish/security/2004/CAN-2004-0077.wml: INITIAL -> 1.1
polish/security/2004/CAN-2004-0109.wml: INITIAL -> 1.1
polish/security/2004/dsa-423.wml: 1.3 -> 1.4
polish/security/2004/dsa-432.wml: 1.2 -> 1.3
polish/security/2004/dsa-445.wml: 1.2 -> 1.3
polish/security/2004/dsa-446.wml: 1.3 -> 1.4
polish/security/2004/dsa-447.wml: 1.2 -> 1.3
polish/security/2004/dsa-462.wml: 1.3 -> 1.4
polish/security/2004/dsa-469.wml: INITIAL -> 1.1
polish/security/2004/dsa-470.wml: INITIAL -> 1.1
polish/security/2004/dsa-471.wml: INITIAL -> 1.1
polish/security/2004/dsa-472.wml: INITIAL -> 1.1
polish/security/2004/dsa-473.wml: INITIAL -> 1.1
polish/security/2004/dsa-474.wml: INITIAL -> 1.1
polish/security/2004/dsa-475.wml: INITIAL -> 1.1
polish/security/2004/dsa-476.wml: INITIAL -> 1.1
polish/security/2004/dsa-477.wml: INITIAL -> 1.1
polish/security/2004/dsa-478.wml: INITIAL -> 1.1
polish/security/2004/dsa-479.wml: INITIAL -> 1.1
polish/security/2004/dsa-480.wml: INITIAL -> 1.1
polish/security/2004/dsa-481.wml: INITIAL -> 1.1
polish/security/2004/dsa-482.wml: INITIAL -> 1.1
polish/security/2004/dsa-483.wml: INITIAL -> 1.1
polish/security/2004/dsa-484.wml: INITIAL -> 1.1
polish/security/2004/dsa-485.wml: INITIAL -> 1.1
polish/security/2004/dsa-486.wml: INITIAL -> 1.1
polish/security/2004/dsa-487.wml: INITIAL -> 1.1
polish/security/2004/dsa-488.wml: INITIAL -> 1.1
polish/security/2004/dsa-489.wml: INITIAL -> 1.1
polish/security/2004/dsa-490.wml: INITIAL -> 1.1
polish/security/2004/dsa-491.wml: INITIAL -> 1.1
polish/security/2004/dsa-492.wml: INITIAL -> 1.1
polish/security/2004/dsa-493.wml: INITIAL -> 1.1
polish/security/2004/dsa-494.wml: INITIAL -> 1.1
polish/security/2004/dsa-531.wml: INITIAL -> 1.1
polish/security/2004/dsa-532.wml: INITIAL -> 1.1
polish/security/2004/dsa-533.wml: INITIAL -> 1.1
polish/security/2004/dsa-534.wml: INITIAL -> 1.1
polish/security/2004/dsa-535.wml: INITIAL -> 1.1
polish/security/2004/dsa-536.wml: INITIAL -> 1.1
polish/security/2004/dsa-538.wml: INITIAL -> 1.1
polish/security/2004/dsa-540.wml: 1.2 -> 1.3
polish/users/index.wml: INITIAL -> 1.1
polish/y2k/index.wml: INITIAL -> 1.1
Diffstat (limited to 'polish/international/Polish/bezpieczny_debian.wml')
-rw-r--r-- | polish/international/Polish/bezpieczny_debian.wml | 720 |
1 files changed, 720 insertions, 0 deletions
diff --git a/polish/international/Polish/bezpieczny_debian.wml b/polish/international/Polish/bezpieczny_debian.wml new file mode 100644 index 00000000000..70e2b429b22 --- /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 >> 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: + +<słowo kluczowe>.<priorytet> <miejsce logwania> + +<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. |