Tworzenie bezpiecznego środowiska kont shellowych

Transkrypt

1 Tworzenie bezpiecznego środowiska kont shellowych Robert Jaroszuk Where you see a feature, I see a flaw... TLUG Uniwersytet Gdański, 8 września 2007

2 Spis Treści 1 Rozpoznanie zagrożeń Zapobieganie - prewencja Ochrona systemu SSH w chroot Wirtualne maszyny Rejestrowanie działań użytkowników Rozbudowa jądra o funkcje podnoszące poziom bezpieczeństwa

3 Rozpoznanie zagrożeń 2 Chcemy się bronić przed: Przejęciem kontroli nad kontem użytkownika, Uruchamianiem nieporządanych usług na kontach użytkowników, Nadużyciami ze strony użytkowników, Nadużyciami ze strony użytkowników, ale skierowanymi na inne systemy, Nieodpowiedzialnością naszych użytkowników

4 Zapobieganie - prewencja 3 Dlatego musimy zapewnić: Poufność Integralność Dostępność Aby to zrobić: Tworzymy odpowiednie reguły i procedury dotyczące przetwarzania informacji POLITYKĘ BEZPIECZEŃSTWA (oczywiście dla jednego serwera nikt tego nie robi, jednak w większych projektach jest to wskazane)

5 Zapobieganie - prewencja 4 Aby nasza (formalna czy też nie) polityka bezpieczeństwa funkcjonowała poprawnie, wymagane są pewne narzędzia: Dla weryfikacji integralności Tripwire / bsign / AIDE Dla poufności SSH / SSL / GPG / etc. Dla uwierzytelniania PAM / polityka haseł, Czy to wszystko co można zrobić? Czy w pełni ufamy powyższym rozwiązaniom? Czy jesteśmy pewni że w 100% zabezpieczą nas przed atakiem?

6 Zapobieganie - prewencja 5 Co więcej można zrobić? Izolowanie użytkowników w wirtualnym środowisku (chroot), Izolowanie użytkowników w wirtualnym systemie (VMware / Xen) Logowanie na zdalne maszyny w bezpiecznej sieci, Rejestrowanie działań użytkowników (logowanie exec*(), logowanie poleceń wpisanych w powłoce) Rozszerzenie zabezpieczeń jądra systemu (grsec / selinux)

7 Ochrona systemu SSH chroot 6

8 Ochrona systemu SSH chroot 7 Zalety: - prostota rozwiązania - dużo informacji (tutoriali) i narzędzi dostępnych w sieci Wady: - Ograniczamy jedynie dostęp do głównego systemu, a nie do zasobów systemowych (moc CPU, pamięć) Informacje na temat chroot dla SSH:

9 Wirtualne maszyny 8 Zalety: - izolujemy wirtualny system od głównego systemu - możemy ograniczać zasoby (CPU / RAM / dysk) - towrzymy kompletne wirtualne serwery Wady: - dużo więcej pracy niż w przypadku chroot

10 Wirtualne maszyny 9

11 Wirtualne maszyny 10

12 Rejestrowanie działań użytkowników 11 Rejestrowanie wywołań funkcji exec*(): - Snoopy LEL - Modifkacja źródeł powłoki: - Rejestrowanie zdarzeń systemowych na zdalnej maszynie - syslogd / syslog-ng

13 Rozbudowa jądra o funkcje podnoszące poziom bezpieczeństwa 12 Dlaczego musimy chronić kernel? Co istotnego znajduje się w jądrze, że wymaga dodatkowej ochrony? Co musimy chronić? Pamięć ICP, komunikacja sieciowa, RAM, reguły firewall Zasoby dyskowe pliki, bootloadery, partycje Sprzęt urządzenia (ioctl, surowy dostęp), EPROMy, konfigurowalne podzespoły serwera JAK chronić? Zapytania (polecenia) muszą przechodzić przez kernel Syscalle, sysctl i sterowniki urządzeń powinny być miejscem w którym zapytania i polecenia są weryfikowane pod kątem bezpieczeństwa.

14 Rozbudowa jądra o funkcje podnoszące poziom bezpieczeństwa 13 Openwall: Stworzony przez Solar Designera (Alexander Peslyak) w 1998 roku (jądro 2.0). - uniemożliwia wykonanie kodu na stosie procesu (ochrona przed niektórymi exploitami). - randomizuje adresy funkcji bibliotecznych (uniemożliwia return-into-libc). - ochrona /proc, ochrona deskryptorów 0 1 2, ochrona linków i FIFO w /tmp PaX i grsecurity: - PaX rozwijany od roku 2000 do 2005 przez zespół PaX. Od 2005 przez Bradleya Spenglera (Spender), autora grsec. - ochrona stosu oraz randomizacja pamięci. - zaawansowana ochrona chroot(); - ochrona /dev/mem, /dev/kmem, /dev/port - /proc/pid/ipaddr, - bogate rejestrowanie zdarzeń w systemie - UDEREF / MEMORY_SANTINIZE - RBAC

15 Rozbudowa jądra o funkcje podnoszące poziom bezpieczeństwa 14 LIDS (Linux Intrusion Detection System): - umożliwia nadawanie praw dostępu do zasobów systemowych (pliki, katalogi, funkcje sieciowe itp.) - SELinux (Security Enhanced Linux): - stworzony w roku 2000 przez NSA. Pierwotnie dodatek do jądra, ale od wersji 2.5 został z nim zintegrowany. - oparty o techniki FLASK każdy podmiot (proces) obiekt (plik, urządzenie) w systemie ma przypisant kontekst (zbiór atrybutów bezpieczeństwa) i nie może wykraczać poza ten zbiór. - RSBAC (Rule Set Base Access Control) - bardzo rozbudowany projekt, stabilna wersja istnieje od 2000r. - informacje o użytkownikach (passwd / shadow) trzymane są w jądrze a nie w plikach (wymaga to wymiany modułów PAM i części bibliotek systemowych). - nakłada ograniczenia na funkcję setuid() - wymaga autoryzacji - listy kontroli dostępu oraz role - ochrona pamięci procesów (PaX), ochrona chroot(), ochrona zasobów, ochrona /proc oraz wiele innych.

16 Koniec 15 Dziękuję za uwagę. Pytania? Prezentacja będzie dostępna pod adresem: