TL; DR. W tym artykule badamy schematy wzmacniania, które działają od razu w pięciu popularnych dystrybucjach Linuksa. Dla każdego z nich przyjęliśmy domyślną konfigurację jądra, załadowaliśmy wszystkie pakiety i przeanalizowaliśmy schematy bezpieczeństwa w załączonych plikach binarnych. Uwzględniane dystrybucje to OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 i 7, a także Ubuntu 14.04, 12.04 i 18.04 LTS.

Wyniki potwierdzają, że nawet podstawowe schematy, takie jak układanie kanarków w stosy i kod niezależny od pozycji, nie zostały jeszcze przyjęte przez wszystkich. Sytuacja jest jeszcze gorsza w przypadku kompilatorów, jeśli chodzi o ochronę przed lukami w zabezpieczeniach, takimi jak kolizja stosów, która znalazła się w centrum uwagi w styczniu po publikacji informacje o lukach systemowych. Ale nie wszystko jest takie beznadziejne. Znaczna liczba plików binarnych implementuje podstawowe metody ochrony, a ich liczba rośnie z wersji na wersję.

Przegląd wykazał, że najwięcej metod ochrony zaimplementowano w Ubuntu 18.04 na poziomie systemu operacyjnego i aplikacji, a następnie w Debianie 9. Z kolei OpenSUSE 12.4, CentOS 7 i RHEL 7 implementują również podstawowe schematy ochrony i ochronę przed kolizją stosu jest używany jeszcze szerzej ze znacznie gęstszym zestawem domyślnych pakietów.

Wprowadzenie

Trudno jest zapewnić wysoką jakość oprogramowania. Pomimo ogromnej liczby zaawansowanych narzędzi do statycznej analizy kodu i dynamicznej analizy runtime, a także znacznego postępu w rozwoju kompilatorów i języków programowania, współczesne oprogramowanie w dalszym ciągu cierpi na luki, które są stale wykorzystywane przez atakujących. Sytuacja jest jeszcze gorsza w ekosystemach zawierających starszy kod. W takich przypadkach stajemy nie tylko przed odwiecznym problemem znalezienia możliwych błędów, które można wykorzystać, ale ograniczają nas rygorystyczne ramy kompatybilności wstecznej, które często wymagają od nas zachowania ograniczonego lub, co gorsza, podatnego na ataki lub błędnego kodu.

W tym miejscu wchodzą w grę metody ochrony lub utwardzania programów. Niektórym typom błędów nie jesteśmy w stanie zapobiec, ale możemy utrudnić życie atakującemu i częściowo rozwiązać problem zapobiegając lub uniemożliwiając eksploatacja te błędy. Taka ochrona jest stosowana we wszystkich nowoczesnych systemach operacyjnych, ale metody różnią się znacznie pod względem złożoności, wydajności i wydajności: od kanarków stosowych i ASLR do pełnej ochrony SPI и RPO. W tym artykule przyjrzymy się, jakie metody ochrony są stosowane w najpopularniejszych dystrybucjach Linuksa w domyślnej konfiguracji, a także zbadamy właściwości plików binarnych dystrybuowanych za pośrednictwem systemów zarządzania pakietami każdej dystrybucji.

CVE i bezpieczeństwo

Wszyscy widzieliśmy artykuły o tytułach takich jak „Najbardziej podatne na ataki aplikacje roku” lub „Najbardziej podatne na ataki systemy operacyjne”. Zwykle dostarczają statystyki dotyczące całkowitej liczby rekordów dotyczących luk w zabezpieczeniach, np CVE (częste luki w zabezpieczeniach i narażenia), uzyskany z Krajowa baza danych o lukach w zabezpieczeniach (NVD) od NIST i inne źródła. Następnie te aplikacje lub systemy operacyjne są uszeregowane według liczby CVE. Niestety, chociaż CVE są bardzo przydatne do śledzenia problemów oraz informowania dostawców i użytkowników, niewiele mówią o rzeczywistym bezpieczeństwie oprogramowania.

Jako przykład rozważ łączną liczbę CVE w ciągu ostatnich czterech lat dla jądra Linuksa i pięciu najpopularniejszych dystrybucji serwerów, a mianowicie Ubuntu, Debian, Red Hat Enterprise Linux i OpenSUSE.

Rys.. 1

Co nam mówi ten wykres? Czy większa liczba CVE oznacza, że ​​jedna dystrybucja jest bardziej podatna na ataki niż inna? Brak odpowiedzi. Na przykład w tym artykule zobaczysz, że Debian ma silniejsze mechanizmy bezpieczeństwa w porównaniu, powiedzmy, z OpenSUSE lub RedHat Linux, a mimo to Debian ma więcej CVE. Nie muszą one jednak koniecznie oznaczać osłabienia bezpieczeństwa: nawet obecność CVE nie wskazuje, czy luka jest eksploatowany. Oceny istotności wskazują, w jaki sposób prawdopodobnie wykorzystanie luki w zabezpieczeniach, ale ostatecznie możliwość wykorzystania luki zależy w dużym stopniu od zabezpieczeń dostępnych w systemach, których dotyczy luka, oraz od zasobów i możliwości atakujących. Co więcej, brak raportów CVE nie mówi nic o innych niezarejestrowany lub nieznany luki w zabezpieczeniach. Różnica w CVE może wynikać z czynników innych niż jakość oprogramowania, w tym zasobów przeznaczonych na testowanie lub wielkości bazy użytkowników. W naszym przykładzie większa liczba CVE w Debianie może po prostu wskazywać, że Debian dostarcza więcej pakietów oprogramowania.

Oczywiście system CVE dostarcza przydatnych informacji, które pozwalają na stworzenie odpowiednich zabezpieczeń. Im lepiej rozumiemy przyczyny niepowodzeń programu, tym łatwiej jest zidentyfikować możliwe metody eksploatacji i opracować odpowiednie mechanizmy wykrywanie i reagowanie. Na ryc. 2 pokazuje kategorie podatności dla wszystkich dystrybucji na przestrzeni ostatnich czterech lat (źródło). Od razu staje się jasne, że większość CVE można podzielić na następujące kategorie: odmowa usługi (DoS), wykonanie kodu, przepełnienie, uszkodzenie pamięci, wyciek informacji (eksfiltracja) i eskalacja uprawnień. Chociaż wiele CVE jest liczonych wielokrotnie w różnych kategoriach, generalnie te same problemy występują rok po roku. W dalszej części artykułu ocenimy zastosowanie różnych schematów ochrony, aby zapobiec wykorzystaniu tych luk.

Rys.. 2

zadania

W tym artykule zamierzamy odpowiedzieć na następujące pytania:

• Jakie jest bezpieczeństwo różnych dystrybucji Linuksa? Jakie mechanizmy ochrony istnieją w aplikacjach jądra i przestrzeni użytkownika?
• Jak zmieniało się na przestrzeni czasu wdrażanie mechanizmów bezpieczeństwa w różnych dystrybucjach?
• Jakie są średnie zależności pakietów i bibliotek dla każdej dystrybucji?
• Jakie zabezpieczenia są zaimplementowane dla każdego pliku binarnego?

Wybór dystrybucji

Okazuje się, że trudno jest znaleźć dokładne statystyki dotyczące instalacji dystrybucyjnych, ponieważ w większości przypadków liczba pobrań nie odzwierciedla liczby rzeczywistych instalacji. Jednak większość systemów serwerowych stanowią warianty Unixowe (na serwerach WWW 69,2% wg statystyki W3techs i inne źródła), a ich udział stale rośnie. Dlatego w naszych badaniach skupiliśmy się na dystrybucjach dostępnych od razu na platformie Google Cloud. W szczególności wybraliśmy następujący system operacyjny:

Dystrybucja/wersja
Rdzeń
Zbudować

OpenSUSE 12.4
4.12.14-95.3-domyślny
#1 SMP śr. 5 grudnia 06:00:48 UTC 2018 (63a8d29)

Debian 9 (rozciągnięty)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018)

6.10 CentOS
2.6.32-754.10.1.el6.x86_64
#1 SMP wtorek, 15 stycznia, 17:07:28 UTC 2019

7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP piątek 1 lutego 14:54:57 UTC 2019

Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP środa 21 listopada 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP czw. 15 listopada 17:36:42 UTC 2018

Ubuntu 14.04 (Zaufany Tahr)
4.4.0–140 — ogólny

#166~14.04.1 — Ubuntu SMP, sobota, 17 listopada, 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1 – Ubuntu SMP piątek 7 grudnia 09:59:47 UTC 2018

Ubuntu 18.04 (Bioniczny Bóbr)
4.15.0–1026-gcp
#27 – Ubuntu SMP czw. 6 grudnia 18:27:01 UTC 2018 r.

Tabela 1

Analiza

Przyjrzyjmy się domyślnej konfiguracji jądra, a także właściwościom pakietów dostępnych za pośrednictwem menedżera pakietów każdej dystrybucji. Dlatego bierzemy pod uwagę tylko pakiety z domyślnych serwerów lustrzanych każdej dystrybucji, ignorując pakiety z niestabilnych repozytoriów (takich jak „testowe” serwery lustrzane Debiana) i pakiety stron trzecich (takie jak pakiety Nvidii ze standardowych serwerów lustrzanych). Ponadto nie bierzemy pod uwagę niestandardowych kompilacji jądra ani konfiguracji o podwyższonych zabezpieczeniach.

Analiza konfiguracji jądra

Zastosowaliśmy skrypt analityczny oparty na darmowy program do sprawdzania kconfig. Przyjrzyjmy się gotowym parametrom ochrony wymienionych dystrybucji i porównajmy je z listą z Podstawowy projekt samoobrony (KSPP). Dla każdej opcji konfiguracji Tabela 2 opisuje żądane ustawienie: pole wyboru dotyczy dystrybucji zgodnych z zaleceniami KSSP (objaśnienie terminów znajduje się poniżej). tutaj; W przyszłych artykułach wyjaśnimy, ile z tych metod bezpieczeństwa powstało i jak zhakować system w przypadku ich braku).

Ogólnie rzecz biorąc, nowe jądra mają bardziej rygorystyczne ustawienia od razu po wyjęciu z pudełka. Na przykład w systemach CentOS 6.10 i RHEL 6.10 w jądrze 2.6.32 brakuje większości krytycznych funkcji zaimplementowanych w nowszych jądrach, takich jak SMAP, ścisłe uprawnienia RWX, randomizacja adresów lub ochrona przed kopiowaniem. Należy zaznaczyć, że wiele opcji konfiguracyjnych z tabeli nie jest dostępnych w starszych wersjach jądra i nie ma zastosowania w rzeczywistości - w tabeli nadal jest to sygnalizowane jako brak odpowiednich zabezpieczeń. Podobnie, jeśli w danej wersji nie ma opcji konfiguracyjnej, a bezpieczeństwo wymaga wyłączenia tej opcji, uważa się to za rozsądną konfigurację.

Kolejna kwestia do rozważenia podczas interpretacji wyników: niektóre konfiguracje jądra, które zwiększają powierzchnię ataku, można również wykorzystać ze względów bezpieczeństwa. Takie przykłady obejmują uproby i kprobes, moduły jądra i BPF/eBPF. Naszym zaleceniem jest wykorzystanie powyższych mechanizmów w celu zapewnienia rzeczywistej ochrony, ponieważ ich użycie nie jest trywialne, a ich wykorzystanie zakłada, że ​​złośliwi aktorzy zadomowili się już w systemie. Jeśli jednak te opcje są włączone, administrator systemu musi aktywnie monitorować nadużycia.

Przyglądając się bliżej wpisom w Tabeli 2, widzimy, że nowoczesne jądra zapewniają kilka opcji ochrony przed wykorzystaniem luk, takich jak wyciek informacji i przepełnienie stosu/sterty. Zauważamy jednak, że nawet najnowsze popularne dystrybucje nie zaimplementowały jeszcze bardziej złożonej ochrony (na przykład za pomocą łatek gwarancje) lub nowoczesne zabezpieczenie przed atakami polegającymi na ponownym użyciu kodu (np. połączenie randomizacji ze schematami takimi jak R^X dla kodu). Co gorsza, nawet te bardziej zaawansowane zabezpieczenia nie chronią przed pełnym zakresem ataków. Dlatego dla administratorów systemów niezwykle ważne jest uzupełnienie inteligentnych konfiguracji rozwiązaniami oferującymi wykrywanie i zapobieganie exploitom w czasie wykonywania.

Analiza aplikacji

Nic dziwnego, że różne dystrybucje mają różne cechy pakietów, opcje kompilacji, zależności bibliotek itp. Różnice istnieją nawet w przypadku związane z dystrybucje i pakiety z niewielką liczbą zależności (na przykład coreutils w Ubuntu lub Debianie). Aby ocenić różnice, pobraliśmy wszystkie dostępne pakiety, wyodrębniliśmy ich zawartość oraz przeanalizowaliśmy pliki binarne i zależności. Dla każdego pakietu śledziliśmy inne pakiety, od których jest on zależny, a dla każdego pliku binarnego śledziliśmy jego zależności. W tej części krótko podsumowujemy wnioski.

Dystrybucje

W sumie pobraliśmy 361 556 pakietów dla wszystkich dystrybucji, wyodrębniając tylko pakiety z domyślnych serwerów lustrzanych. Zignorowaliśmy pakiety bez plików wykonywalnych ELF, takich jak źródła, czcionki itp. Po przefiltrowaniu pozostało 129 569 pakietów zawierających łącznie 584 457 plików binarnych. Rozkład pakietów i plików w różnych dystrybucjach pokazano na rys. 3.

Rys.. 3

Zauważysz, że im nowocześniejsza dystrybucja, tym więcej zawiera pakietów i plików binarnych, co jest logiczne. Jednak pakiety Ubuntu i Debian zawierają znacznie więcej plików binarnych (zarówno plików wykonywalnych, jak i modułów dynamicznych i bibliotek) niż CentOS, SUSE i RHEL, co potencjalnie wpływa na powierzchnię ataku Ubuntu i Debiana (należy zauważyć, że liczby odzwierciedlają wszystkie pliki binarne wszystkich wersji pakiet, czyli niektóre pliki są analizowane kilkukrotnie). Jest to szczególnie ważne, gdy rozważa się zależności pomiędzy pakietami. Zatem luka w pojedynczym pakiecie binarnym może mieć wpływ na wiele części ekosystemu, tak jak podatna na ataki biblioteka może mieć wpływ na wszystkie pliki binarne, które ją importują. Na początek przyjrzyjmy się rozkładowi liczby zależności pomiędzy pakietami w różnych systemach operacyjnych:

Rys.. 4

W prawie wszystkich dystrybucjach 60% pakietów ma co najmniej 10 zależności. Ponadto niektóre pakiety mają znacznie większą liczbę zależności (ponad 100). To samo dotyczy odwrotnych zależności pakietów: zgodnie z oczekiwaniami kilka pakietów jest używanych przez wiele innych pakietów w dystrybucji, więc luki w zabezpieczeniach w tych kilku wybranych pakietach stanowią duże ryzyko. Jako przykład, poniższa tabela zawiera listę 20 pakietów z maksymalną liczbą odwrotnych zależności w SLES, Centos 7, Debian 9 i Ubuntu 18.04 (każda komórka wskazuje pakiet i liczbę odwrotnych zależności).

Tabela 3

Interesujący fakt. Chociaż wszystkie analizowane systemy operacyjne są zbudowane dla architektury x86_64, a większość pakietów ma architekturę zdefiniowaną jako x86_64 i x86, pakiety często zawierają pliki binarne dla innych architektur, jak pokazano na rysunku 5. XNUMX.

Rys.. 5

W następnej sekcji zagłębimy się w charakterystykę analizowanych plików binarnych.

Statystyki ochrony plików binarnych

Jako absolutne minimum musisz poznać podstawowy zestaw opcji bezpieczeństwa dla istniejących plików binarnych. Do kilku dystrybucji Linuksa dołączone są skrypty przeprowadzające takie kontrole. Na przykład Debian/Ubuntu ma taki skrypt. Oto przykład jego pracy:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

Skrypt sprawdza pięć funkcje ochronne:

• Plik wykonywalny niezależny od pozycji (PIE): wskazuje, czy sekcja tekstowa programu może zostać przeniesiona w pamięci w celu uzyskania randomizacji, jeśli w jądrze włączona jest funkcja ASLR.
• Ochrona stosu: czy kanarki stosowe są włączone w celu ochrony przed atakami kolizyjnymi ze stosami.
• Wzmocnij źródło: czy niebezpieczne funkcje (na przykład strcpy) są zastępowane ich bezpieczniejszymi odpowiednikami, a wywołania sprawdzane w czasie wykonywania są zastępowane ich niesprawdzonymi odpowiednikami (na przykład memcpy zamiast __memcpy_chk).
• Relokacje tylko do odczytu (RELRO): czy wpisy w tabeli relokacji są oznaczone jako tylko do odczytu, jeśli zostaną wywołane przed rozpoczęciem wykonywania.
• Natychmiastowe wiązanie: czy linker środowiska wykonawczego pozwala na wszystkie ruchy przed rozpoczęciem wykonywania programu (jest to równoważne pełnemu RELRO).

Czy powyższe mechanizmy są wystarczające? Niestety nie. Znane są sposoby na ominięcie wszystkich powyższych zabezpieczeń, jednak im mocniejsza obrona, tym wyższa poprzeczka dla atakującego. Na przykład, Metody obejścia RELRO trudniejsze do zastosowania, jeśli obowiązuje PIE i natychmiastowe wiązanie. Podobnie pełny ASLR wymaga dodatkowej pracy, aby stworzyć działający exploit. Jednak wyrafinowani napastnicy są już przygotowani na sprostanie takim zabezpieczeniom: ich brak zasadniczo przyspieszy włamanie. Dlatego istotne jest, aby środki te uznać za konieczne minimum.

Chcieliśmy zbadać, ile plików binarnych w omawianych dystrybucjach jest chronionych tymi i trzema innymi metodami:

• Bit niewykonalny (NX) uniemożliwia wykonanie w dowolnym regionie, który nie powinien być wykonywalny, takim jak sterta stosu itp.
• ŚCIEŻKA/ŚCIEŻKA RUN oznacza ścieżkę wykonania używaną przez dynamiczny moduł ładujący w celu znalezienia pasujących bibliotek. Pierwszy jest obowiązkowe w przypadku każdego nowoczesnego systemu: jego brak umożliwia atakującym dowolne zapisanie ładunku w pamięci i wykonanie go w niezmienionej postaci. Po drugie, nieprawidłowe konfiguracje ścieżek wykonania pomagają we wprowadzeniu zawodnego kodu, który może prowadzić do szeregu problemów (np. eskalacja przywilejówa także inne problemy).
• Ochrona przed kolizjami stosu zapewnia ochronę przed atakami, które powodują, że stos nakłada się na inne obszary pamięci (takie jak sterta). Biorąc pod uwagę niedawne nadużywanie exploitów luki w zabezpieczeniach związane z kolizją sterty systemowejuznaliśmy za stosowne uwzględnić ten mechanizm w naszym zbiorze danych.

Zatem bez zbędnych ceregieli przejdźmy do liczb. Tabele 4 i 5 zawierają podsumowanie analizy odpowiednio plików wykonywalnych i bibliotek różnych dystrybucji.

• Jak widać, ochrona NX jest wdrażana wszędzie, z nielicznymi wyjątkami. W szczególności można zauważyć jego nieco mniejsze wykorzystanie w dystrybucjach Ubuntu i Debian w porównaniu do CentOS, RHEL i OpenSUSE.
• W wielu miejscach brakuje kanarków stosowych, szczególnie w dystrybucjach ze starszymi jądrami. Pewien postęp widać w najnowszych dystrybucjach Centos, RHEL, Debian i Ubuntu.
• Z wyjątkiem Debiana i Ubuntu 18.04, większość dystrybucji ma słabą obsługę PIE.
• Ochrona przed kolizją stosu jest słaba w OpenSUSE, Centos 7 i RHEL 7 i praktycznie nie istnieje w innych.
• Wszystkie dystrybucje z nowoczesnym jądrem obsługują w pewnym stopniu RELRO, przy czym na czele znajduje się Ubuntu 18.04, a na drugim miejscu znajduje się Debian.

Jak już wspomniano, metryki w tej tabeli są średnią dla wszystkich wersji pliku binarnego. Jeśli spojrzysz tylko na najnowsze wersje plików, liczby będą inne (np Postęp Debiana we wdrażaniu PIE). Co więcej, większość dystrybucji zazwyczaj testuje bezpieczeństwo tylko kilku funkcji binarnych podczas obliczania statystyk, ale nasza analiza pokazuje prawdziwy procent funkcji, które są wzmocnione. Zatem jeśli w systemie binarnym chronionych będzie 5 z 50 funkcji, przyznamy mu ocenę 0,1, co odpowiada 10% wzmocnionych funkcji.

Tabela 4. Charakterystyki bezpieczeństwa plików wykonywalnych pokazane na rys. 3 (realizacja odpowiednich funkcji jako procent całkowitej liczby plików wykonywalnych)

Tabela 5. Charakterystyki zabezpieczeń bibliotek pokazanych na rys. 3 (realizacja odpowiednich funkcji jako procent całkowitej liczby bibliotek)

Czy jest zatem postęp? Zdecydowanie tak: widać to po statystykach poszczególnych dystrybucji (np. Debian), a także z powyższych tabel. Jako przykład na ryc. Rysunek 6 przedstawia implementację mechanizmów ochronnych w trzech kolejnych dystrybucjach Ubuntu LTS 5 (pominęliśmy statystyki ochrony przed kolizją stosu). Zauważamy, że z wersji na wersję coraz więcej plików obsługuje kanarkowe stosy, a także coraz więcej plików binarnych jest dostarczanych z pełną ochroną RELRO.

Rys.. 6

Niestety, wiele plików wykonywalnych w różnych dystrybucjach nadal nie ma żadnego z powyższych zabezpieczeń. Na przykład, patrząc na Ubuntu 18.04, zauważysz plik binarny ngetty (zamiennik getty), a także powłoki mksh i lksh, interpreter picolisp, pakiety nvidia-cuda-toolkit (popularny pakiet dla aplikacji akcelerowanych przez GPU takie jak struktury uczenia maszynowego) i klibc -utils. Podobnie, plik binarny mandos-client (narzędzie administracyjne, które pozwala automatycznie ponownie uruchamiać komputery z zaszyfrowanymi systemami plików), a także rsh-redone-client (ponowna implementacja rsh i rlogin) są dostarczane bez ochrony NX, chociaż mają prawa SUID: (. Ponadto kilka plików binarnych suid nie ma podstawowej ochrony, takiej jak kanarki stosowe (na przykład plik binarny Xorg.wrap z pakietu Xorg).

Podsumowanie i uwagi końcowe

W tym artykule podkreśliliśmy kilka funkcji bezpieczeństwa nowoczesnych dystrybucji Linuksa. Analiza wykazała, że ​​najnowsza dystrybucja Ubuntu LTS (18.04) implementuje średnio najsilniejszą ochronę na poziomie systemu operacyjnego i aplikacji spośród dystrybucji ze stosunkowo nowymi jądrami, takich jak Ubuntu 14.04, 12.04 i Debian 9. Natomiast zbadane dystrybucje CentOS, RHEL i OpenSUSE w naszym zestawie domyślnie generuje gęstszy zestaw pakietów, a w najnowszych wersjach (CentOS i RHEL) ma wyższy procent ochrony przed kolizją stosu w porównaniu do konkurentów opartych na Debianie (Debian i Ubuntu). Porównując wersje CentOS i RedHat, zauważamy duże usprawnienia w implementacji kanarków stosowych i RELRO z wersji 6 do 7, ale średnio CentOS ma zaimplementowanych więcej funkcji niż RHEL. Ogólnie rzecz biorąc, wszystkie dystrybucje powinny zwracać szczególną uwagę na ochronę PIE, która z wyjątkiem Debiana 9 i Ubuntu 18.04 jest zaimplementowana w mniej niż 10% plików binarnych w naszym zbiorze danych.

Na koniec należy zaznaczyć, że chociaż badanie przeprowadziliśmy ręcznie, dostępnych jest wiele narzędzi bezpieczeństwa (np. Lynis, Tygrys, Hubble), które przeprowadzają analizę i pomagają uniknąć niebezpiecznych konfiguracji. Niestety nawet silna ochrona w rozsądnych konfiguracjach nie gwarantuje braku exploitów. Dlatego jesteśmy głęboko przekonani, że należy to zapewnić niezawodne monitorowanie i zapobieganie atakom w czasie rzeczywistym, koncentrując się na wzorcach wyzysku i zapobieganiu im.

Źródło: www.habr.com