14.2. Wprowadzenie

Bezpieczeństwo to funkcja zaczynająca się i kończąca administratorem systemu. O ile wszystkie wieloużytkownikowe systemy BSD UNIX® mają pewien poziom bezpieczeństwa, rola zbudowania i utrzymania dodatkowych mechanizmów zabezpieczających mających “zadowolić” użytkowników jest prawdopodobnie największym wyzwaniem dla administratora. Systemy są na tyle bezpieczne, na ile zostaną skonfigurowane a zagadnienia związane z bezpieczeństwem zawsze konkurują z naturalną ludzką potrzebą posiadania wygodnego środowiska pracy. Systemy UNIX są zdolne do wykonywania dużej ilości jednoczesnych procesów, przy czym wiele z nich pracuje jako serwery -- co oznacza, że zewnętrzne jednostki mogą łączyć się do nich i porozumiewać się. Wraz z gwałtowną ewolucją wczorajszych mini i super-komputerów, które stały się dzisiaj standardowym sprzętem używanym w domu i nierzadko połączonych z siecią, bezpieczeństwo staje się poważnym problemem.

Bezpieczeństwo najlepiej implementować w oparciu o model podzielonej na warstwy “cebuli”. Sprowadza się do to tego, że należy stworzyć jak najwięcej warstw bezpieczeństwa zachowując równowagę z wygodą używania systemu a następnie monitorować system pod kątem intruzów. Nie chcemy z pewnością przesadzić z poziomem bezpieczeństwa, ponieważ wpłynie to na efektywność wykrywania -- a jest ono najważniejszym aspektem mechanizmów bezpieczeństwa. Na przykład, nie ma większego sensu ustawiać flagi schg (patrz chflags(1)) na każdym binarnym pliku systemowym, ponieważ o ile tymczasowo chroni to je, uniemożliwia włamywaczowi dokonanie łatwo wykrywalnej zmiany. Doprowadzi to w wyniku do tego, że mechanizmy wykrywania włamań po prostu nie zauważą ataku.

Bezpieczeństwo systemu dotyczy również różnych form ataku, włączając w to te mające na celu załamanie pracy poszczególnych aplikacji czy całego systemu, czy generalnie mające na celu destabilizacje pracy nie koniecznie przez uzyskanie dostępu do konta root. Zagadnienia bezpieczeństwa można podzielić na parę kategorii:

  1. Ataki typu Denial of Service.

  2. Włamania na konta użytkowników.

  3. Włamania na konto root poprzez dostępne serwery.

  4. Włamania na konto root przez konta użytkowników.

  5. Stworzenie tylnego wejścia.

Odmowa Usługi (Denial of Service) to rodzaj ataku pozbawiający atakowaną maszynę potrzebnych jej zasobów. Zwykle, ataki DoS opierają się na mechanizmie używającym rozwiązania siłowego, próbującym załamać atakowaną maszynę lub spowodować że usługi przez nią udostępnianie staną się nieosiągalne - przez atak na stos serwera lub samej maszyny. Niektóre z ataków DoS próbują wykorzystać błędy w stosie sieciowym, co zwykle możliwe jest nawet za pomocą jednego pakietu. Tym ostatnim atakom można zapobiec aplikując łatę do jądra, natomiast atakom na serwery przez odpowiednie ustawienie opcji tak, by zmniejszyć obciążenie powodowane przez nie w przypadku skrajnie niekorzystnych warunków. Sieciowe ataki siłowe są trudniejsze do powstrzymania. Na przykład, atak z użyciem sfałszowanych adresów pakietów jest praktycznie niemożliwy do powstrzymania - a powoduje odcięcie systemu od Internetu. Być może nie spowoduje załamania się Twojej maszyny, ale wysyci łącze z Internetem do tego stopnia, że jakikolwiek prawdziwy ruch na nim stanie się niemożliwy.

Włamania na konto użytkownika są powszechniejsze niż ataki DoS. Wielu administratorów nadal używa standardowych serwerów telnetd, rlogind, rshd i ftpd. Są one domyślnie skonfigurowane tak, by nie używać połączeń szyfrowanych. W wyniku tego, jeśli mamy już całkiem pokaźną liczbę użytkowników, niektórzy z nich zaczną logować się ze zdalnych lokalizacji (ponieważ będzie to dla nich wygodniejsze) - co umożliwi podsłuchanie ich haseł. Uważny administrator systemu będzie sprawdzał logi z połączeń, analizując adresy z których były wykonywane nawet dla połączeń zakończonych sukcesem.

Należy zawsze zakładać, że gdy atakujący uzyska dostęp do konta użytkownika, może również uzyskać dostęp do konta root. W świecie rzeczywistym, w dobrze zabezpieczonym i zarządzanym systemie jest to jednak tylko możliwość teoretyczna. Różnica jest zasadnicza, ponieważ bez dostępu do konta root atakujący nie może zwykle ukryć swoich śladów ani zrobić nic oprócz skasowania plików użytkownika. Włamania na konto użytkownika zdarzają się bardzo często, ponieważ zwykli użytkownicy nie przykładają takiej uwagi do bezpieczeństwa jak administratorzy systemów.

Administratorzy systemów muszą zdawać sobie sprawę, że jest wiele potencjalnych sposobów uzyskania dostępu do konta root. Atakujący może znać hasło na to konto, znaleźć dziurę w demonie pracującym z prawami roota i wykorzystać ją przez połączenie sieciowe, lub w demonie pracującym z prawami suid-root i wykorzystać ją korzystając z konta zwykłego użytkownika. W sytuacji, w której atakujący ma sposób dostępu bezpośrednio do konta root, nie musi już zawracać sobie głowy instalowaniem tylnej furtki. Wiele z dziur związanych z dostępem do konta root wykrytych i poprawionych do tej pory, wiązało się z dosyć pokaźną pracą wykonaną przez atakującego by zatrzeć po sobie ślady, tak więc zwykle pozostawiają oni po sobie właśnie tylne furtki. Tylna furtka umożliwia atakującemu łatwy dostęp do konta root, ale daje również możliwość mądremu administratorowi wykrycia intruza. Uniemożliwienie zainstalowania tylnej furtki może nie być tak korzystne jak się wydaje - ponieważ nie naprawia tak naprawdę sedna problemu.

Zabiegi mające na celu zabezpieczenie systemu powinny być zawsze implementowane w ramach wielowarstwowego modelu, opartego na modelu “cebuli”. Można je skategoryzować następująco:

  1. Zabezpieczenie konta root i administratorów.

  2. Zabezpieczenie serwerów pracujących z uprawnieniami root oraz binarnych plików suid/sgid.

  3. Zabezpieczenie kont użytkowników.

  4. Zabezpieczenie pliku z hasłami.

  5. Zabezpieczenie jądra systemu, urządzeń surowych i systemu plików.

  6. Szybkie wykrywanie niedopuszczalnych zmian dokonywanych w systemie.

  7. Paranoja.

Następna sekcja tego rozdziału zajmie się powyższymi punktami dokładniej.

Ten i inne dokumenty można pobrać z ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

W przypadku pytań o FreeBSD prosimy przeczytać dostępną dokumentację przed kontaktem z <questions@FreeBSD.org>.
W sprawie zapytań o tę dokumentację prosimy o kontakt z <doc@FreeBSD.org>.