Bawię się bindem i zacząłem zastanawiać się, dlaczego to oprogramowanie działa na przykład w CentOS w chroot. Nie zrozum mnie źle, wiem, co to jest bind i do czego służy chroot (więzienie). Ale moje główne pytanie brzmi: czy wiązanie działa z każdym chrootem, tak bardzo niepewnym?
Czy naprawdę szkodliwe jest konfigurowanie go bez więzienia (bardziej niż jakakolwiek inna usługa lub oprogramowanie). W systemach jest wiele procesów uruchomionych bez chroota i myślę, że kompromis jakiegokolwiek z nich jest bardzo niebezpieczny, ale co czyni nazwanie bardziej niebezpiecznym niż inne oprogramowanie działające bez chroota?
Odpowiedzi:
Jak wspomniał @Some Guy, musisz o tym pomyśleć z perspektywy historycznej.
Historyczna perspektywa była taka, że jeden element sprzętowy składał się z kilkunastu różnych usług w ramach jednego systemu operacyjnego. Jeśli jedna usługa została naruszona, wszystko na tym sprzęcie zostało naruszone.
W przypadku wirtualizacji jest to o wiele mniejszy problem. Chociaż ucieczka z maszyny wirtualnej nie jest niemożliwa, nie jest trywialna. Z pewnością trudniej jest wyrwać się z maszyny wirtualnej, niż proces działający z uprawnieniami roota wyrwać się z chroota. Więc moje serwery powiązań działają na własnej maszynie wirtualnej. W tym przypadku naprawdę nie ma sensu chroot, ponieważ obrażenia są już ograniczone po prostu przez fakt, że jest to VM.
Chroot to bardzo słaba próba stworzenia czegoś w rodzaju maszyny wirtualnej. Chroots może uciec przed dowolnym procesem z uprawnieniami roota. Chroot nie jest przeznaczony i nie działa jako mechanizm bezpieczeństwa. Chroot z więzieniem BSD lub LXC zapewnia wirtualizację na poziomie systemu operacyjnego i zapewnia funkcje bezpieczeństwa. Ale w dzisiejszych czasach, kiedy tak łatwo jest rozruszać nową maszynę wirtualną całego komputera, konfiguracja lub nauczenie się korzystania z narzędzi do wirtualizacji na poziomie systemu operacyjnego może nie być warte wysiłku.
Wcześniejsze wersje wiązania nie powodowały utraty uprawnień. W systemie Unix tylko konto root może otwierać porty poniżej 1024, a Bind, jak wszyscy wiemy, musi nasłuchiwać na udp / 53 i tcp / 53. Ponieważ Bind zaczyna się jako root i nie odrzuca uprawnień, żaden kompromis oznaczałby, że cały system mógłby zostać naruszony. Prawie każde oprogramowanie w tych dniach zacznie otwierać swoje gniazda i robić inne rzeczy, które wymagają uprawnień roota, a następnie zmienią użytkownika, którego używają, na konto nieuprzywilejowane. Po zniesieniu uprawnień wpływ naruszenia bezpieczeństwa jest znacznie niższy niż w systemie hosta.
źródło
Inne odpowiedzi są całkiem dobre, ale nie wspominają o koncepcji bezpieczeństwa warstw. Każda warstwa bezpieczeństwa, którą dodajesz do systemu, to kolejna warstwa, którą przeciwnik musi pokonać. Umieszczenie BIND w chroot dodaje jeszcze jedną przeszkodę.
Powiedzmy, że w BIND istnieje luka, którą można wykorzystać, i ktoś może wykonać dowolny kod. Jeśli są w chroot, muszą się z tego wyrwać, zanim przejdą do czegokolwiek innego w systemie. Jak wspomniano, do złamania chroot wymagane są uprawnienia roota. BIND nie działa jako root, i w chroot powinny znajdować się minimalne narzędzia, co dodatkowo ogranicza opcje i zasadniczo pozostawia tylko wywołania systemowe. Jeśli nie ma wywołania systemowego w celu eskalacji uprawnień, przeciwnik utknął na twoich rekordach DNS.
Wspomniana sytuacja jest nieco nieprawdopodobna, jak wspomina SomeGuy, BIND ma obecnie dość słabych punktów i są one głównie ograniczone do scenariuszy typu DoS, a nie do zdalnego wykonywania. To powiedziawszy, uruchamianie w chroot jest domyślną konfiguracją na wielu systemach operacyjnych, więc jest mało prawdopodobne, abyś podejmował z twojej strony wysiłek, aby zachować tak nieznacznie zwiększone bezpieczeństwo.
źródło
preambuła
ciągle słyszę, jak ludzie powtarzają nieporozumienia z całego Internetu .. dlatego postaram się wyjaśnić
po pierwsze; ile było przypadkowych odkryć, które po prostu… z powodu przyczyny i skutku zostały wykorzystane do czegoś innego niż zamierzony cel?
czym było i czym jest więzienie Chroot
Chroot został początkowo zaprojektowany do zmiany katalogu głównego dla procesu lub użytkownika (świetny do kompilacji oprogramowania z nieznanych źródeł). zapewniło to bezpieczeństwo systemu podstawowego, a także urządzenie do szybkiego łóżka testowego, w tym łatwe czyszczenie. od tego czasu minęły lata, a jego koncepcja i dorozumiane zastosowania z pewnością również się zmieniły.
chroot został skutecznie wykorzystany i znajduje się bezpośrednio w bazie kodu dla kilku programów i bibliotek (tj. openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot i wiele więcej ). zakładanie, że wszystkie te główne aplikacje wdrożyły wadliwe rozwiązania bezpieczeństwa, jest po prostu nieprawdą
chroot to rozwiązanie do wirtualizacji systemu plików: nic więcej, nic więcej. założenie, że możesz łatwo wydostać się z chroota, również nie jest prawdą ... o ile przestrzegasz wytycznych dotyczących uruchamiania procesów w więzieniu chroot.
kilka kroków, aby zabezpieczyć więzienie chroot
tj. NIE uruchamiaj procesów jako ROOT. może to otworzyć główny wektor eskalacji (co jest również prawdziwe w chroot lub poza nim). nie uruchamiaj procesu w chroot, używając tego samego użytkownika co inny proces poza chroot. oddzielić każdy proces i użytkownika do własnego Chroota, aby ograniczyć powierzchnie ataku i zapewnić prywatność. montuj tylko niezbędne pliki, biblioteki i urządzenia. wreszcie chroot NIE jest zamiennikiem bezpieczeństwa systemu podstawowego. zabezpieczyć system w całości.
inna ważna uwaga: wiele osób uważa, że OpenVZ jest zepsuty lub że nie jest on równy w porównaniu z pełną wirtualizacją systemu. przyjmują to założenie, ponieważ jest to zasadniczo Chroot, a stół do procesu jest sterylizowany. ze środkami bezpieczeństwa na sprzęcie i urządzeniach. z których większość można wdrożyć w chroot.
nie każdy administrator ma poziom wiedzy niezbędny do zabezpieczenia wszystkich niezbędnych parametrów jądra na dedykowanym serwerze lub przy pełnej wirtualizacji systemu. oznacza to, że wdrożenie OpenVZ oznacza, że Twoi klienci będą mieli znacznie mniej powierzchni do ataku, aby spróbować i zabezpieczyć się przed wdrożeniem swoich aplikacji. dobry host wykona dobrą robotę, zabezpieczając te parametry, a to z kolei jest lepsze nie tylko dla wszystkich w węźle lub centrum danych, ale dla całego Internetu ...
jak wspomniano, chroot zapewnia wirtualizację systemu plików. musisz upewnić się, że nie ma żadnych plików wykonywalnych setuid, niezabezpieczonych aplikacji, bibliotek, zwisających dowiązań symbolicznych bez właściciela itp. jeśli atakujący MUSI złamać powiązanie, będzie musiał przeszukać wirtualny system plików w celu wykrycia bufora przed przepełnieniem, gry z deskryptorami plików lub w jakiś inny sposób narazić na szwank coś przebywającego w chroocie - zwykle uciekając z więzienia poprzez eskalację przywilejów lub wstrzyknięcie jego lub jej ładunku do systemu podstawowego.
jeśli tak się dzieje, zwykle jest to wynikiem złej aktualizacji, exploita zero-day lub idiomatycznego błędu ludzkiego .
dlaczego chroot jest nadal używany, w przeciwieństwie do pełnej wirtualizacji systemu
rozważ ten scenariusz: korzystasz z wirtualnego serwera prywatnego z węzłem hosta z OpenVZ. po prostu nie możesz uruchomić niczego, co działa na poziomie jądra. oznacza to również, że nie można używać wirtualizacji systemu operacyjnego do oddzielania procesów i zapewniać dodatkowe bezpieczeństwo. dlatego MUSISZ użyć chroot do tego celu.
ponadto chroot jest zrównoważony w każdym systemie, niezależnie od dostępnych zasobów. najprościej mówiąc, ma najmniejszy narzut dowolnego typu wirtualizacji. oznacza to, że jest to nadal ważne w wielu niskiej jakości urządzeniach.
rozważ inny scenariusz: masz apache działający w środowisku zwirtualizowanym. chcesz oddzielić każdego użytkownika. zapewnienie zwirtualizowanego systemu plików poprzez dodanie chroota do apache (mod_chroot, mod_security itp.) byłoby najlepszą opcją dla zapewnienia maksymalnej prywatności między użytkownikami końcowymi. pomaga to również zapobiegać gromadzeniu danych wywiadowczych i zapewnia jeszcze jedną warstwę bezpieczeństwa.
najprościej mówiąc, ważne jest, aby wprowadzić zabezpieczenia w warstwach . Chroot może być jednym z nich. nie każdy i każdy system ma luksus dostępu do jądra, dlatego chroot STILL służy temu celowi. istnieje wiele aplikacji, w których wirtualizacja całego systemu jest w zasadzie nadmierna.
W odpowiedzi na twoje pytanie
Nie korzystam szczególnie z CentOS, ale wiem, że Bind teraz traci swoje uprawnienia przed operacjami. Zakładam jednak, że wiązanie jest chrootowane ze względu na historię wektorów ataku i potencjalne luki w zabezpieczeniach.
także ... sensowniejsze jest automatyczne uruchamianie tej aplikacji, ponieważ nie KAŻDY ma dostęp do pełnej wirtualizacji na poziomie systemu / systemu operacyjnego. to z kolei teoretycznie pomaga zapewnić bezpieczeństwo użytkownikom CentOS:
dostawcy systemów operacyjnych po prostu nie obchodzą, zakładając, że każdy z nich ma ten sam system. w ten sposób mogą pomóc zapewnić dodatkową warstwę bezpieczeństwa w ogóle ...
istnieje powód, dla którego tak wiele aplikacji z niego korzysta , i oczywiście, że twój system operacyjny domyślnie tak działa: ponieważ jest on używany jako funkcja bezpieczeństwa i działa. przy starannym przygotowaniu, jak wcześniej wspomniano, jest to kolejna przeszkoda, którą potencjalny atakujący musi przezwyciężyć - przez większość czasu, ograniczając szkody do wyrządzonych tylko więzieniu chroot.
źródło
Wynika to częściowo z przyczyn historycznych, gdy starsze wersje Bind miały poważne, częste luki w zabezpieczeniach. Naprawdę nie śledziłem tego tematu na bieżąco, ale założę się, że znacznie się poprawił od czasów złych czasów.
Drugim powodem, bardziej praktycznym, jest to, że zazwyczaj jest wdrażany w roli internetowej, i jako taki, jest otwarty na więcej ataków, sondowania i ogólne psoty.
Dlatego, jak to często bywa w praktyce, ogólna zasada: lepiej być bezpiecznym niż żałować, szczególnie, że wysiłek chrootowania jest stosunkowo niewielki.
źródło