Tworzenie bezpiecznego środowiska kont shellowych

Tworzenie bezpiecznego
środowiska kont shellowych
Robert Jaroszuk
<[email protected]>
“Where you see a feature, I see a flaw...”
TLUG
Uniwersytet Gdański, 8 września 2007
1
Spis Treści
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
Robert Jaroszuk <[email protected]>
2
Rozpoznanie zagrożeń
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
Robert Jaroszuk <[email protected]>
Zapobieganie - prewencja
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)
Robert Jaroszuk <[email protected]>
3
Zapobieganie - prewencja
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?
Robert Jaroszuk <[email protected]>
4
Zapobieganie - prewencja
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)
Robert Jaroszuk <[email protected]>
5
Ochrona systemu – SSH chroot
Robert Jaroszuk <[email protected]>
6
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:
http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.en.html
http://chrootssh.sourceforge.net/
http://paradigma.pt/~gngs/sshjail
Robert Jaroszuk <[email protected]>
8
Wirtualne maszyny
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
Robert Jaroszuk <[email protected]>
9
Wirtualne maszyny
Robert Jaroszuk <[email protected]>
10
Wirtualne maszyny
Robert Jaroszuk <[email protected]>
Rejestrowanie działań użytkowników
Rejestrowanie wywołań funkcji exec*():
- Snoopy - http://sourceforge.net/projects/snoopylogger/
- LEL - http://zim.iq.pl/code/lel.tgz
Modifkacja źródeł powłoki:
- http://zim.iq.pl/code/bash-3.1-logexec.tgz
Rejestrowanie zdarzeń systemowych na zdalnej maszynie
- syslogd / syslog-ng
Robert Jaroszuk <[email protected]>
11
Rozbudowa jądra o funkcje podnoszące poziom bezpieczeństwa
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.
Robert Jaroszuk <[email protected]>
12
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
Robert Jaroszuk <[email protected]>
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.
Robert Jaroszuk <[email protected]>
15
Koniec
Dziękuję za uwagę.
Pytania ?
Prezentacja będzie dostępna pod adresem:
http://linux.gda.pl/spotkania
Robert Jaroszuk <[email protected]>