path: root/polish/international/Polish/bezpieczny_debian.wml

#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.