[ Pobierz całość w formacie PDF ]
.Ma to sens tylko wtedy, je¿eli czêsto logujesz siê jako root.Du¿o lepiej jest prze-kazywaæ pocztê u¿ytkownika root na w³asne konto, ustawiaj¹c alias pocztowywed³ug opisu w rozdziale 19, Exim, lub rozdziale 18, Sendmail.ChoæbyS skonfigurowa³ swój oSrodek z najwiêksz¹ dba³oSci¹, zgodnie z prawamiMurphy'ego i tak wyst¹pi jakiS problem.Dlatego utrzymywanie systemu oznacza ta-k¿e przyjmowanie skarg.Zwykle ludzie spodziewaj¹ siê, ¿e z administratorem sys-temu mo¿na skontaktowaæ siê poczt¹ elektroniczn¹ pod adresem root, ale istniej¹ ta-k¿e inne adresy, które s¹ powszechnie u¿ywane do kontaktu z osobami odpowie-dzialnymi za konkretny aspekt utrzymania oSrodka.Na przyk³ad skargi na tematb³êdnej konfiguracji poczty zwykle bêd¹ wysy³ane na adres postmaster, a problemyz grupami dyskusyjnymi mog¹ byæ raportowane na adres newsmaster lub usenet.Poczta na adres hostmaster powinna byæ przekierowana do osoby odpowiedzialnejza podstawowe us³ugi sieciowe hosta i us³ugi DNS, je¿eli na twojej maszynie dzia³aserwer nazw.Bezpieczeñstwo systemuKolejnym, bardzo istotnym aspektem administracji systemu w Srodowisku siecio-wym jest zabezpieczenie go i jego u¿ytkowników przed intruzami.Niedbalezarz¹dzane systemy stanowi¹ ³atwy cel dla z³oSliwych osób.Ataki zaczynaj¹ siê odzgadywania hase³, a koñcz¹ na wysy³aniu fa³szywych pakietów Ethernet, natomiastzniszczenia zaczynaj¹ siê od fa³szywych poczt elektronicznych, a mog¹ skoñczyæ siêutrat¹ danych lub pogwa³ceniem prywatnoSci twoich u¿ytkowników.O pewnych Utrzymywanie systemu 16konkretnych problemach powiemy przy omawianiu kontekstu, w którym mog¹ onewyst¹piæ, i poka¿emy sposoby obrony.Ten podrozdzia³ omawia kilka przyk³adów i podstawowych technik zwi¹zanychz bezpieczeñstwem systemu.OczywiScie nie przedstawia wszystkich zagadnieñbezpieczeñstwa, jakie mo¿esz napotkaæ.Chcemy jedynie zasygnalizowaæ problemy,które mog¹ wyst¹piæ.Dlatego przeczytanie dobrej ksi¹¿ki na temat bezpieczeñstwajest absolutnie niezbêdne, szczególnie w przypadku systemu sieciowego.Podstaw¹ bezpieczeñstwa systemu jest dobra administracja.Oznacza to sprawdza-nie w³asnoSci wszystkich istotnych plików i katalogów oraz prawa dostêpu do nich,a tak¿e monitorowanie wykorzystania uprzywilejowanych kont.Na przyk³ad pro-gram COPS przeszukuje twój system plików i podstawowe pliki konfiguracyjne podk¹tem nietypowych praw dostêpu lub innych anomalii.M¹drze jest tak¿e u¿ywaætakiego systemu hase³, który wymaga od u¿ytkowników stosowania siê do pewnychregu³, przez co has³a jest trudno odgadn¹æ.Na przyk³ad pakiet hase³ shadow wyma-ga, by has³o mia³o co najmniej 5znaków i zawiera³o liczby oraz znaki niealfanume-ryczne.Gdy udostêpniasz jak¹S us³ugê w sieci, pamiêtaj, ¿eby daæ jej jak najmniej przy-wilejów .Pozwalaj na robienie tylko tych rzeczy, które s¹ wymagane, by dzia³a³atak, jak zosta³a zaprojektowana.Na przyk³ad powinieneS nadaæ programom prawosetuid roota lub innego uprzywilejowanego konta, tylko wtedy gdy jest to niezbêd-ne.Tak¿e, je¿eli chcesz u¿ywaæ us³ugi tylko w bardzo ograniczonym zakresie, niewahaj siê jej skonfigurowaæ odpowiednio do twoich szczególnych zastosowañ.Naprzyk³ad gdybyS chcia³ pozwoliæ, aby stacje bezdyskowe uruchamia³y siê z twojejmaszyny, musisz udostêpniæ uproszczony protokó³ przesy³ania plików (Trivial FileTransfer Protocol TFTP), tak by mog³y skopiowaæ podstawowe pliki konfiguracyjnez katalogu /boot twojej maszyny.Jednak w przypadku nieograniczonego u¿yciaTFTP pozwala u¿ytkownikom z ca³ego Swiata kopiowaæ te pliki z twojego systemu,do których wszyscy maj¹ prawo odczytu.Je¿eli sobie tego nie ¿yczysz, ograniczus³ugê TFTP jedynie do katalogu /boot*.Mo¿esz równie¿ ograniczyæ us³ugi przyznawane u¿ytkownikom okreSlonych host-ów, powiedzmy z twojej sieci lokalnej.W rozdziale 12 przedstawiamy demon tcpd,który wykonuje to zadanie dla wielu aplikacji sieciowych.Bardziej wyrafinowanemetody ograniczania dostêpu do poszczególnych hostów lub us³ug omówimyw rozdziale 9.Kolejn¹ wa¿n¹ rzecz¹ jest unikanie niebezpiecznego oprogramowania.W pew-nym sensie ka¿de oprogramowanie mo¿e byæ niebezpieczne, poniewa¿ mo¿e zawie-raæ b³êdy, które sprytni ludzie mog¹ wykorzystaæ, by uzyskaæ dostêp do twojegosystemu.Takie rzeczy siê zdarzaj¹ i nie da siê przed tym zabezpieczyæ.Problem tendotyczy zarówno oprogramowania darmowego, jak i produktów komercyjnych**.* Do tego tematu powrócimy w rozdziale 12, Wa¿ne funkcje sieciowe.** Zdarza³y siê komercyjne wersje Uniksa (za które p³aci³o siê mnóstwo pieniêdzy), których skryp-ty pow³oki mia³y tak ustawione prawo setuid root, ¿e u¿ytkownik móg³ bez trudu uzyskaæ przywilejeroota za pomoc¹ standardowej sztuczki. Utrzymywanie systemu 17Jednak programy wymagaj¹ce specjalnych przywilejów s¹ z natury bardziej nara-¿one na niebezpieczeñstwo ni¿ pozosta³e, poniewa¿ wszelkie luki mog¹ prowadziædo powa¿nych konsekwencji*.Je¿eli instalujesz program z prawem setuid, który mapracowaæ z sieci¹, b¹dx dwa razy bardziej ostro¿ny i przeczytaj dokumentacjê, abySprzez przypadek nie stworzy³ dziury w bezpieczeñstwie.Uwagê powinieneS zwróciæ tak¿e na programy, które pozwalaj¹ na logowanie lubwykonywanie poleceñ z niepe³nym uwierzytelnianiem.Polecenia, takie jak rlogin,rsh i rexec, s¹ bardzo przydatne, ale od osoby uruchamiaj¹cej wymagaj¹ jedynie ogra-niczonego uwierzytelnienia, które opiera siê na zaufaniu do nazwy wywo³uj¹cegohosta, ustalonej na podstawie serwera nazw (bêdziemy mówili o tym póxniej), któr¹³atwo mo¿na sfa³szowaæ.Obecnie standardow¹ praktyk¹ powinno byæ zupe³newy³¹czanie poleceñ r i zastêpowanie ich narzêdziami z pakietu ssh [ Pobierz caÅ‚ość w formacie PDF ]