Polecenia a Protokoły: W tym dokumencie używamy tekstu pogrubionego odnosząc się do polecenia lub nazwy aplikacji. W ten sposób będzie oznaczane na przykład ssh, ponieważ jest zarówno protokołem jak i poleceniem.
Poniższe sekcje opisują metody zabezpieczania systemu FreeBSD, wyliczone w sekcji ostatniej sekcji tego rozdziału.
Po pierwsze, nie zajmuj się zabezpieczaniem kont zespołu, jeśli nie zabezpieczyłeś najpierw konta roota. Większość systemów ma przypisane hasło do tego konta. Na początek należy założyć że atakujący zawsze może skompromitować to konto. Nie oznacza to absolutnie, że powinieneś usunąć hasło do niego. Jest ono prawie zawsze niezbędne dla dostępu przez konsolę. Oznacza to natomiast, że powinieneś uniemożliwić użycie tego hasła z połączenia innego niż konsola, lub nawet przez polecenie su(1). Na przykład, upewnij się że pty oznaczone są jako `insecure' w pliku /etc/ttys, co spowoduje że logowanie bezpośrednio na konto roota przez telnet lub rlogin są niemożliwe. Jeśli używasz innych usług logowania, takich jak sshd upewnij się, że w jego konfiguracji też zabroniono bezpośredniego logowania na konto roota. Można to wykonać, edytując plik /etc/ssh/sshd_config i upewniając się że dyrektywa PermitRootLogin ustawiona jest na NO. Przejrzyj konfigurację wszystkich usług - takie jak np. FTP bardzo często stają się celem udanych ataków. Logowanie wprost na konto roota powinny być możliwe tylko przez konsolę systemową.
Oczywiście, jako administrator systemu będziesz musiał czasami użyć uprawnień konta root, więc otworzymy na tą okazję parę dziur. Upewnimy się jednak, że wymagają one dodatkowych haseł. Jednym ze sposobów na zapewnienie takiej funkcjonalności jest dodanie kont zespołu do grupy wheel w pliku /etc/group. Konta zespołu, włączone do grupy wheel mogą użyć polecenia su by wejść na konto root. Nigdy nie powinieneś dodawać członkom zespołu po prostu członkostwa w grupie wheel przez dopisanie do listy ich grup również grupy wheel. Wszyscy członkowie zespołu powinni należeć do grupy staff a dopiero później dodani do grupy wheel w pliku /etc/group. Tylko ci członkowie zespołu, którzy faktycznie potrzebują dostępu do konta roota powinni zostać dopisani dodatkowo do grupy wheel. W przypadku stosowania usług takich jak Kerberos, można skorzystać z pliku .k5login konta root by umożliwić ksu(1) na konto roota bez dopisywania kogokolwiek do grupy wheel. Może to być lepsze rozwiązanie, ponieważ mechanizm wheel nadal umożliwia dostęp do konta roota, jeśli intruzowi uda się uzyskać plik z hasłami i złamać hasło któregoś z członków zespołu. Tak więc, o ile stosowanie mechanizmu wheel jest lepsze niż nie stosowanie czegokolwiek, ale nie jest to najbezpieczniejsze rozwiązanie.
Pośrednim sposobem zabezpieczenia kont zespołu i dostępu do konta roota jest ``wygwiazdkowanie'' zaszyfrowanych haseł z kont zespołu. Za pomocą polecenia vipw(8) możesz zastąpić każde hasło pojedyńczym znakiem ``*''. Polecenie to uaktualni plik /etc/master.passwd i bazę danych użytkownik/hasło, uniemożliwiając logowanie z użyciem hasła.
Wpis dla konta członka zespołu, takiego jak to:
foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
Powinno być zmienione do takiej postaci:
foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
Zmiana ta uniemożliwi normalne logowanie, ponieważ zaszyfrowane hasło nigdy nie będzie pasować do ciągu ``*''. W tym momencie użytkownicy muszą używać innych usług uwierzytelniania, takich jak użycie pary kluczy publicznego i prywatnego w usługach kerberos(1) czy ssh(1). Przy użyciu usługi takiej jak Kerberos, należy zabezpieczyć maszyny pracujące jako serwery usługi Kerberos, oraz swoją stację roboczą. Mechanizm kluczy publiczny/prywatny używany przez ssh wymaga zabezpieczenia tylko maszyny z której się logujesz ( zwykle stacji roboczej ). Dodatkową warstwą ochronną w tym przypadku, może stać się zabezpieczenie pary kluczy używanych do logowania przez hasło stworzone poleceniem ssh-keygen(1). Zastąpienie ``gwiazdką'' haseł zespołu gwarantuje również, że mogą się oni logować tylko przez bezpieczne usługi uwierzytelniające, które skonfigurowałeś. Zmusza to wszystkich członków zespołu do używania szyfrowanych połączeń, zamykając tym samym istotną dziurę potencjalnie dostępną dla intruzów: podsłuchanie logowania z innej, niezabezpieczonej stacji.
Mniej bezpośrednie mechanizmy bezpieczeństwa zakładają zwykle, że logujesz się z bardziej restryktywnego serwera na mniej restryktywny. Na przykład, jeśli na twojej maszynie pracuje wiele demonów-serwerów, na twojej stacji nie powinny pracoważ żadne. Aby zapewnić, że twoja stacja robocza jest jak najbardziej bezpieczna, powinieneś ograniczyć ilość uruchamianej na niej usług do minimum - włącznie z wyłączeniem wszystkich usług i włączenie zabezpieczonego hasłem wygaszacza ekranu. Oczywiście po uzyskaniu bezpośredniego dostępu do maszyny, atakujący może złamać każdy rodzaj zabezpieczenia. Jest to z pewnością problem, który powinieneś rozważyć, ale musisz wziąć pod uwagę, że większość włamań dokonują ludzie nie posiadający bezpośredniego dostępu do twojej maszyny - przez sieć.
Zastosowanie mechanizmu takiego jak Kerberos umożliwia dezaktywację lub zmianę haseł dla kont zespołu w jednym miejscu i rozpowszechnienie tej informacji natychmiast wśród wszystkich maszyn, na których dana osoba ma konto. Jeśli takie konto zostanie skompromitowane, możliwość natychmiastowej zmiany hasła na wszystkich maszynach powinna zostać doceniona. W przypadku nie stosowania zcentralizowanych usług uwierzytelniania, zmiana haseł na N maszynach może być prawdziwym problemem. Z pomocą Kerberosa możesz również nałożyć ograniczenia na zmiany haseł: przyznany w procesie logowania żeton uwierzytelniający może wygasać a system może żądać wybrania nowego hasła po upływie określonego czasu ( powiedzmy, po miesiącu ).
Rozsądny administrator uruchamia tylko te demony, które musi - ni mniej, ni więcej. Weź pod uwagę, że serwery firm trzecich są najczęściej dziurawe. Na przykład, używanie starej wersji demona imapd lub popper daje uniwersalny dostęp do konta root dowolnej osobie z całego świata. Nigdy nie uruchamiaj serwerów, których dokładnie nie sprawdziłeś. Wiele z nich, nie potrzebuje wcale praw roota - na przykład demony takie jak ntalk, comsat i finger mogą pracować w specjalnie przygotowanych piaskownicach. Piaskownica nie jest mechanizmem doskonałym, chyba że wpakujesz się w duże kłopoty, ale zasada cebuli ma dalej zastosowanie: po włamaniu do serwera w piaskownicy, atakujący musi się jeszcze z niej wydostać. Czym więcej warstw, które musi on pokonać w drodze do panowania nad twoją maszyną, tym mniejsze prawdopodobieństwo że osiągnie sukces. Dziury w kontach demonów pracujących z prawami roota znaleziono praktycznie w każdym serwerze, włączając w to te zupełnie podstawowe. Jeśli twoi użytkownicy logują się przez sshd a nigdy przez telnetd, rshd czy rlogind, wyłącz te usługi!
Obecnie FreeBSD domyślnie skonfigurowany jest na uruchamianie usług ntalkd, comsat i finger w piaskownicy. Kolejnym programem dobrze dostosowanym do pracy w tym środowisku może być named(8). Plik /etc/defaults/rc.conf zawiera domyślnie wykomentowane parametry niezbędne by named pracował w piaskownicy. W zależności od tego, czy instalujesz nowy system czy uaktualniasz istniejący, konta używane przez środowisko może istnieć bądź nie. Ostrożny administrator sprawdzi które z usług mogą zostać zamknięte w piaskownicy i zamknie je w nich.
Wiele usług zwykle nie pracuje w piaskownicy: sendmail, popper, imapd, ftpd i inne. Dla większości z nich istnieją alternatywy, ale zainstalowanie ich może wymagać więcej wysiłku niż chciałbyś włożyć ( czynnik wygody w użytkowaniu pojawia się ponownie ). Być może będziesz musiał uruchomić te usługi z uprawnieniami roota i zaufać, że inne mechanizmy wykryją ewentualne włamanie.
Innymi potencjalnymi zagrożeniami, są te powodowane przez binaria z prawami suid-root i sgid. Większość z nich znajduje się w katalogach /bin, /sbin, /usr/bin i /usr/sbin ( np. rlogin ). O ile nic nie jest nigdy 100% bezpieczne, pliki z ustawionymi domyślnie atrybutami suid i sgid powinny być uważane za generalnie bezpieczne. Od czasu do czasu znajduje się jednak dziury w tych usługach - w 1998 znaleziono dziurę w Xlib, umożliwiającą uzyskanie praw roota przez aplikację xterm ( pracującą zwykle z prawami suid ). Zawsze lepiej jest być zabezpieczonym, niż później żałować takiego przeoczenia - ostrożny administrator ustawi restrykcje na binariach suid tak, by tylko członkowie zespołu mogli je uruchamiać i jednocześnie pozbędzie się ( (chmod 000 ) wszystkich binariów z prawami suid, których nikt nie używa. Serwer bez zdefiniowanych ekranów nie będzie zwykle używał programu xterm. Binaria z atrybutem sgid również mogą być prawie tak samo groźne. Włamywacz, który włamie się do binarium sgid-kmem, może odczytać /dev/kmem a w związku z tym odczytać zaszyfrowany plik z hasłami - potencjalnie kompromitując dowolne konto. Innym przykładem może być włamywacz, uzyskujący dostęp do grupy kmem - może monitorować klawisze wciskane na pty, włączając w to pty używane przez użytkowników logujących się za pomocą bezpiecznych usług uwierzytelniających. Włamywacz, który uzyskał dostęp do grupy tty może pisać do terminala prawie każdego użytkownika. Jeśli użytkownik pracuje w programie z emulacją klawiatury, intruz może potencjalnie wygenerować ciąg danych powodujący, że terminal użytkownika wykona jakąś komendę jako ten legalny użytkownik systemu.
Konta użytkowników są zwykle najtrudniejsze do zabezpieczenia. O ile możesz wymusić Drakońskie restrykcje w dostępie na kontach zespołu i ``wygwiazdkować'' ich konta, możesz nie być w stanie zrobić tego z innymi kontami. Jeśli posiadasz odpowiednią kontrolę, możesz wygrać i być w stanie zapezpieczyć konta użytkowników właściwie. Jeśli nie, musisz być po prostu czujny i monitorować to co się dzieje. Zastosowanie ssh czy Kerberosa dla kont użytkowników może być problematyczne, z uwagi na dodatkowe zagadnienia administracyjne i konieczność zapewnienia wsparcia technicznego, ale nadal jest to bardzo dobre rozwiązanie w porównaniu do szyfrowanego pliku z hasłami.
Jedynym bezpiecznym sposobem jest wpisanie * zamiast haseł w tak wielu kontach jak tylko możesz i używanie ssh lub Kerberosa do uwierzytelniania dostępu do tych kont. Pomimo tego, że plik z zaszyfrowanymi hasłami ( /etc/spwd.db ) może być odczytany tylko przez roota, intruz może uzyskać prawa czytania do tego pliku bez potrzeby uzyskiwania praw pisania.
Twoje skrypty sprawdzające bezpieczeństwo powinny zawsze sprawdzić i ewentualnie zaraportować zmiany w pliku z hasłami ( patrz sekcja Sprawdzanie integralności plików poniżej ).
Intruz po uzyskaniu dostępu do konta roota może zrobić praktycznie wszystko, ale można wskazać pewne wzorce. Na przykład, większość nowoczesnych kerneli ma sterownik do urządzenia umożliwiającego podsłuchiwanie pakietów. We FreeBSD urządzenie to nazywa się bpf. Intruz zwykle postara się uruchomić sniffer na maszynie na którą się włamał. Nie musisz mu ułatwiać zadania i w większości zastosowań nie potrzebujesz mieć wkompliowanego w kernel tego urządzenia.
Jednak nawet jeśli wyłączysz obsługę urządzenia bpf, nadal masz na głowie /dev/mem i /dev/kmem. Jeśli o nie chodzi, intruz może nadal pisać po surowych urządzeniach. Istnieje również inna cecha kernela zwana loaderem modułów, kldload(8). Przewidujący czy wyrafinowany intruz może użyć KLD do załadowania własnego urządzenia bpf lub dowolnego, innego urządzenia do pracującego kernela. Aby zapobiec tego typu problemom, ustaw system tak, by pracował na wyższym poziomie bezpieczeństwa, przynajmniej na securelevel 1. Można to wykonać poleceniem sysctl ustawiając wartość zmiennej kern.securelevel. Po ustawieniu poziomu 1, zapis na urządzeniach surowych będzie zabroniony, wejdą również w życie restrykcje związane z ustalonymi poleceniem chflags flagami, takimi jak schg. Upewnij się, że wszystkie krytyczne binaria oraz skrypty startowe mają ustawioną flagę schg. Nie jest to specjalnie wygodne, a uaktualnienie systemu jest dużo trudniejsze niż na niższych poziomach trudności. Kompromisem w tej sytuacji jest pracowanie w wyższym trybie bezpieczeństwa, ale z flagami schg ustawionymi tylko wybiórczo na niektórych, najważniejszych skryptach i programach. Jeszcze inna możliwość to podmontowanie katalogów / i /usr w trybie tylko do odczytu. Ponownie w tym momencie należy przypomnieć, że zbyt Drakońskie ograniczenia mogą uniemożliwić Ci wykrycie intruza.
To zagadnienie w zasadzie sprowadza się tylko do kontroli ograniczonego zestawu głównych plików konfiguracyjnych systemu i plików kontrolnych, bo w pewnym momencie pojawia się ponownie zagadnienie wygody użytkowania systemu. Na przykład, użycie programu chflags do ustawienia bitu schg na większości plików w katalogach / i /usr jest prawdopodobnie trochę za daleko idące, ponieważ o ile uniemożliwia zmiany w tych plikach, uniemożliwia również wykrycie potencjalnego intruza. Ostatnią warstwą naszego modelu bezpieczeństwa ( cebuli ) jest najbardziej istotna - wykrycie. Reszta zabiegów związanych z bezpieczeństwem może okazać się zupełnie bezużyteczna ( lub, gorzej, dać fałszywe poczucie bezpieczeństwa ) jeśli nie jesteś w stanie określić czy faktycznie coś się stało czy nie. Połowa warstw naszej cebuli to zagadnienia mające spowolnić włamywacza a nie go zatrzymać - w tym czasie pozostałe mechanizmy powinny umożliwić jego skuteczne i precyzyjne wykrycie na gorącym uczynku.
Najprościej zidentyfikować intruza sprawdzając czy nie zmodyfikowano, usunięto lub nie dodano jakiś plików. A najlepiej robić to z innego ( zwykle centralnego ) systemu z ograniczonym dostępem. Skonstruowanie swoich skryptów bezpieczeństwa w ten sposób, by umożliwiały sprawdzenie zdalne, powoduje że nasze zabiegi stają się prawie niewidoczne dla potencjalnego włamywacza - a jest to istotne. Aby zapewnić sobie maksymalne korzyści płynące z takiego rozwiązania, musisz udostępnić sobie określone zasoby w trybie do czytania albo przez wyeksportowanie przez NFS, albo przez skonfigurowanie kluczy publicznych ssh i użycie tego narzędzia do logowania się na sprawdzane maszyny. Z wyjątkiem ruchu sieciowego, NFS jest najmniej widoczną metodą montowania zasobów, idalną do monitorowania systemów plików na każdej ze stacji klienckich w sposób prawie niewidoczny. Jeśli stacja z której przeprowadzasz sprawdzanie jest podłączona do stacji które sprawdzasz przełącznikiem, metoda stosująca NFS jest najprawdopodobniej najoptymalniejsza. Jeśli natomiast elementem łączącym jest zwykły koncentrator, lub połączenie realizowane jest przez obszerniejszą infrastrukturę sieciową, metoda z NFS może być zbyt niebezpieczna ( z uwagi na możliwość podsłuchania ) i wtedy lepiej użyć ssh.
Po skonfigurowaniu odpowiednich mapowań dysków stacji klienckich, musisz jeszcze napisać skrypty, które będą wykonywały monitoring. Dla NFS, wystarczą najprostsze narzędzia, takie jak find(1) i md5(1). Najlepszą praktyką jest sporządzanie sum kontrolnych md5 plików na stacjach monitorowanych przynajmniej raz na dzień, a plików w katalogach /etc i /usr/local/etc jeszcze częściej. W momencie znalezienia różnic pomiędzy skrótami md5 przechowywanymi w centralnej bazie a faktycznymi plikami na monitorowanym systemie plików, skrypt powinien zawiadomić administratora by to sprawdził. Dobry skrypt sprawdzi również czy nie ustawiono niewłaściwych flag suid na plikach, oraz czy nie pojawiły się lub zniknęły pliki z partycji / oraz /usr.
Zastosowanie ssh zamiast NFS utrudnia trochę napisanie dobrych skryptów. Zwykle będziesz musiał przesłać za pomocą scp skrypty na maszynę sprawdzaną, co od razu sprawi że intruz może zauważyć. Dla bezpieczeństwa, potrzebujesz również przesłać zaufane wersje plików takich jak na przykład find. Weź pod uwagę, że wersja ssh na stacji monitorowanej już może być podmieniona. Tak czy inaczej, użycie ssh może okazać się jedynym wyjściem.
Dobry skrypt powinien sprawdzać również zmiany w plikach takich jak .rhosts, .shosts czy .ssh/authorized_keys w katalogach domowych użytkowników zespołu administrującego.
Być może, jeśli dysponujesz dużą ilością wolnego miejsca, warto sprawdzać wszystkie pliki na partycjach domowych. Przy okazji warto wtedy ustawić przy montowaniu tych systemów plików bity nosuid oraz nodev ( patrz mount(8)). Nawet jeśli nie dysponujesz miejscem, i tak powinieneś wziąć pod uwagę skanowanie partycji domowych raz na tydzień - być może uda ci się wykryć próbę włamania lub włamanie udane.
Rozpatrując zagadnienia spójności i integralności, warto również wspomnieć o rozliczaniu ( patrz accton(8) ). Jest to relatywnie tani w sensie mocy przerobowej mechanizm, mogący ułatwić ocenę strat i zidentyfikowanie zakresu problemu już po włamaniu. Zwykle pomaga on odpowiedzieć na pytanie jak intruz dostał się do systemu.
Ostatnią rzeczą, którą powinny przeglądać skrypty monitorujące są pliki logów - one same natomiast powinny być generowane w sposób bezpieczny. Jeśli możliwe jest logowanie do zdalnego systemu, będzie to na pewno opcja przydatna. Intruz na pewno postara się zatrzeć ślady swojej działalności a należy pamiętać że logi są krytyczne dla administratora próbującego dojść co właściwie i jak się stało. Jednym z bardzo dobrych sposobów zapisu logów jest połączenie przez kabel szeregowy do maszyny, która zapisuje je fizycznie na swój system plików.
Odrobina paranoi nigdy nie boli. Generalna reguła mówi, że administrator systemu może dodać dowolną liczbę mechanizmów mających poprawić bezpieczeństwo, jeśli nie wpływają one na wygodę, oraz ograniczoną liczbę mechanizmów, które na nią wpływają. Co więcej, osoba odpowiedzialna za bezpieczeństwo powinna urozmaicić swoją konfigurację - jeśli używasz rekomendacji zawartych w tym dokumencie dosłownie, cały świat zna metodologię zabezpieczenia twojego systemu.
W sekcji tej opisano ataki Odmowy Usługi. Zwykle są to ataki sieciowe, używające rozmaitych pakietów. O ile niewiele możesz zrobić przeciwko pakietom wysycającym twoje łącze, możesz ograniczyć swoje straty i upewnić się, że twoje serwery od nich nie ucierpią.
Ograniczenie ilości wywołań tego samego programu.
Ograniczenie odpowiedzi na działania złośliwe ( ataki powodujące odpowiedzi ICMP, broadcasty ping itp. )
Pamięć Podręczna Tras Kernela
Najpopularniejsze ataki DoS polegają na zmuszeniu serwera do mnożenia swoich kopii w pamięci - powoduje to marnowanie zasobów takich jak dopuszczalna liczba procesów, deskryptorów plików oraz oczywiście pamięci. W efekcie, maszyna po prostu zamiera. Demon inetd ( patrz inetd(8) ) posiada kilka opcji mogących zapobiec takiemu atakowi. Należy w tym momencie zauważyć, że o ile można w takiej sytuacji uniemożliwić zajęcie wszystkich zasobów systemu, to zapewnienie funkcjonalności danej usługi może okazać się niemożliwe. Zapoznaj się z podręcznikiem inetd, zwracając szczególną uwagę na opcje -c, -C oraz -R. Weź pod uwagę, że ataki z użyciem pakietów ze sfałszowanymi adresami źródłowymi wprowadzą w błąd opcję -C a w związku z tym zapewne musisz użyć zestawu różnych opcji. Niektóre z samodzielnych serwerów posiadają właściwe sobie ograniczenia dotyczące maksymalnej liczby procesów.
Sendmail ma na przykład opcję -OMaxDaemonChildren, która generalnie działa lepiej niż zaimplementowane w nim opcje ograniczania obciążenia. Uważnie dobierz wartość tego parametru - powinna być na tyle wysoka by obsłużyć normalny ruch, ale nie za wysoka jak na możliwości systemu. Wygodna jest również opcja umożliwiająca rozdzielenie obsługi użytkowników ( sendmail -bd ) od obsługi kolejki ( sendmail -q15m ). Jeśli potrzebujesz szybszego rozsyłania poczty, użyj na przykład parametru -q1m, ale upewnij się że podałeś odpowiednią wartość maksymalną dla opcji MaxDaemonChildren tej kopii demona, by zapobiec występującym kaskadowo błędom.
Demon syslogd również może zostać zaatakowany bezpośrednio. Zaleca się użycie opcji -s jeśli to możliwe, a jeśli nie - to przynajmniej -a.
Powinieneś być również ostrożny z usługami łączącymi się do inicjującego połączenie takich jak odwrotny inetd z pakietu tcpwrapper. Generalnie nie chcesz używać tej opcji z uwagi na możliwość zaatakowania jej wprost.
Bardzo dobrym pomysłem jest ochrona usług wewnętrznych przed dostępem z zewnątrz za pomocą odpowiednich ustawień ścian ogniowych na routerach brzegowych. Chodzi tu raczej o uniemożliwienie wykonania ataku z zewnątrz sieci a nie o zabezpieczenie konta roota. Zawsze staraj się skonfigurować wg. zasady ``domyślnie blokuję wszystko - z wyjątkiem portów A, B, C, D i M-Z''. Masz w tym momencie pewność, że umożliwiłeś dostęp tylko do wskazanych wprost usług, takich jak na przykład named ( jeśli jesteś serwerem nadrzędnym dla strefy ), ntalkd, sendmail i innych usług dostępnych przez sieć. Przy podejściu odwrotnym zawsze istnieje ryzyko, że coś zostanie ``przeoczone'' lub dodasz nową usługę i zapomnisz uaktualnić konfigurację ściany ogniowej. Stosując taktykę blokowania wszystkiego możesz oczywiście otworzyć wyższe porty, bez drastycznego spadku bezpieczeństwa i odsłonienia niższych portów. Zauważ również, że we FreeBSD możesz dynamicznie konfigurować zakresy portów, korzystając z polecenia sysctl i drzewa net.inet.ip.portrange ( sprawdź dostępne opcje wydając polecenie sysctl -a | fgrep portrange ). Na przykład, najpierw konfigurujesz normalny zakres portów do użycia od 4000 do 5000, oraz od 49152 do 65535 a następnie blokujesz na ścianie ogniowej wszystko poniżej 4000 ( z wyjątkiem portów przypisanych wykorzystywanym usługom ).
Innym powszechnie spotykanym atakiem jest wymuszenie na serwerze odpowiedzi. Powoduje to zaangażowanie go w bezsensowną pracę i może doprowadzić do przeładowania jego samego, sieci lub innej maszyny. Większość tego typu ataków opiera się o rozgłaszanie pingów ICMP. Atakujący fałszuje pakiety ping wysyłane do ciebie, wstawiając jako adres źródłowy adres ofiary, a jako adres docelowy - adres rozgłoszeniowy twojej sieci LAN. Jeśli routery brzegowe nie odrzucą takiego pakietu, twoja sieć LAN najprawdopodobniej zablokuje ofiarę - szczególnie, jeśli atakujący użyje tej sztuczki na wielu sieciach jednocześnie. Do tej pory zanotowano ataki z użyciem broadcastów do łącznej przepustowości stu dwudziestu megabitów na sekundę. Drugi powszechny atak tego samego typu wykonywany jest przeciwko mechanizmowi informowania przez ICMP o błędach. Tworząc pakiet który wygeneruje w odpowiedzi pakiet ICMP z informacją o błędzie, atakujący może spowodować wysycenie łącza przychodzącego do serwera, oraz sprawić że serwer sam wysyci swoje łącze wychodzące. Ten rodzaj ataku może również spowodować załamanie się serwera z powodu wykorzystania wszystkich buforów sieciowych, w szczególności jeśli sam serwer jest w stanie generować odpowiedzi wystarczająco szybko. Jądro FreeBSD ma opcję ICMP_BANDLIM, umożliwiającą ograniczenie efektywności ataku tego typu. Ostatnią główną klasą ataków tego typu są ataki związane z wewnętrznymi usługami demona inetd, takimi jak echo UDP. Atakujący fałszuje pakiet UDP w ten sposób, że para adres źródłowy/port wskazuje na port echo jednego z serwerów w twojej sieci LAN, a para adres docelowy/port na port echo na innym serwerze, również w twojej sieci LAN. Oba serwery zaczynają wymianę pakietów, mogącą doprowadzić do załamania samych serwerów lub zupełnego zapchania sieci w których się znajdują. Podobny problem istnieje z wewnętrzną obsługą usługi chargen. Kompetentny administrator wyłączy wszystkie usługi bazujące na wewnętrznych mechanizmach inetd.
Sfałszowane pakiety mogą również zostać użyte do przepełnienia pamięci podręcznej tras jądra. Zapoznaj się ze znaczeniem zmiennych sysctl - net.inet.ip.rtexpire, rtminexpire oraz rtmaxcache. Atak używający pakietów ze sfałszowanymi adresami, powoduje zapełnianie bufora tras w pamięci kernela ( można ją przejrzeć, wydając polecenie netstat -rna | fgrep W3 ) - wpisy tego rodzaju zwykle wygasają po około 1600 sekundach. Kernel po wykryciu, że zbuforowana tablica tras stała się zbyt duża, dynamicznie zmniejszy wartość parametru rtexpire, ale nigdy poniżej wartości rtminexpire. Mamy tutaj do czynienia z dwoma problemami:
Kernel nie zareaguje odpowiednio szybko, w przypadku nagłego ataku na słabo obciążony serwer.
Wartość rtminexpire nie jest na tyle niska, by kernel mógł przeżyć uparty atak.
Jeśli przypadkiem twoje serwery podłączone są do Internetu przez łącze E3 lub większe, najlepiej będzie ręcznie dostosować wartość zarówno rtexpire jak i rtminexpire używając do tego sysctl(8). Nigdy nie ustawiaj tych wartości na zero (chyba, że chcesz spowodować załamanie systemu). Ustawienie obu parametrów na 2 sekundy powinno powstrzymać atak na tablicę routingu.
Istnieje parę zagadnien, o których musisz pamiętać implementując usługę Kerberos i/lub ssh. Kerberos V jest doskonałym protokołem uwierzytelniającym, ale w przystosowanych do niego wersjach aplikacji telnet oraz rlogin istnieją błędy, uniemożliwiające użycie ich ze strumieniami binarnymi. Domyślnie, Kerberos nie szyfruje również sesji, chyba że użyjesz parametru -x. ssh szyfruje wszystko domyślnie.
ssh z kolei działa prawie doskonale, oprócz tego że domyślnie przekazuje klucze używane do szyfrowania. Oznacza to, że jeśli masz bezpieczną stację roboczą przechowującą klucze używane przez ciebie do logowania się na inne systemy, podczas logowania się na niezabezpieczoną maszynę możesz ujawnić swoje klucze. Fizycznie klucze nie są dostępne dla każdego, ale ssh instaluje port przekazujący na czas trwania logowania - jeśli intruz złamał już na tej maszynie konto roota, może wykorzystać ten port by użyć twoich kluczy i uzyskać dostęp do maszyn, do których i ty masz dostęp.
Zalecamy, byś jeśli tylko to możliwe używał ssh w połączeniu z Kerberosem dla logowanie na konta zespołu zarządzającego. ssh można skonfigurować ze wsparciem dla Kerberosa. Zmniejsza to twoją zależność od potencjalnie wykorzystywalnych kluczy, a jednocześnie chroni hasła za pomocą Kerberosa. Klucze dla ssh powinny być używane tylko w przypadku automatów, które robią coś z zabezpieczonych stacji ( coś, do czego Kerberos się nie nadaje ). Zalecamy również wyłączenie przekazywania kluczy w konfiguracji ssh, lub wskazanie wprost opcją from=IP/DOMAIN, że ssh ma posługiwać się plikiem authorized_keys do określenia które klucze są dostępne w odniesieniu do konkretnych maszyn, na które się logujesz.
| Poprzedni | Spis treści | Następny |
| Wprowadzenie | Początek rozdziału | DES, MD5 i Crypt |
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the
documentation
before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.