10.2. Wprowadzenie

Bezpieczeństwo to funkcja zaczynająca się i kończąca administratorem systemu. O ile wszystkie wieloużytkownikowe systemy Uniksowe BSD 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 Uniksowe są generalnie 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 zsieciowanym, 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 chcesz 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ń nie zauważą po prostu 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 przez uzyskanie dostępu do konta root. Zagadnienia bezpieczeństwa można podzielić na parę kategorii:

1. ataki typu Denial of service

2. kompromitację kont użytkowników

3. kompromitację konta root przez inne serwery dostępu

4. kompromitację konta root przez konta użytkowników

5. stworzenie tylneo wejścia

Odmowa Usługi to rodzaj ataku pozbawiający atakowaną maszynę potrzebnych jej zasobów. Zwykle, ataki DoS opierają się na mechaniźmie 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 kernela, 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.

Kompromitacja konta użytkownika jest powszechniejsza niż atak 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 masz 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 roota atakujący nie może zwykle ukryć swoich śladów ani zrobić nic oprócz skasowania plików użytkownika. Kompromitacja konta 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 roota. 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 roota, 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 roota, ale daje również możliwość mądremu administratorowi wykrycie 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'' i można je skategoryzować następująco:

1. Zabezpieczenie kont roota i całego zespołu.

2. Zabezpieczenie serwerów pracujących z uprawnieniami roota 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.