Detekcja włamań? Monitoring kluczowych plików w systemie?

[Pół człowiek pół admin]

W sumie nikt mi (chyba :P) nigdy nie wbił na roota przez eskalację uprawnień, czy inne tego typu zabawy rekreacyjno-edukacyjne, ale zastanawiam się od jakiegoś czasu jak w praktyce w miarę sensownie zorganizować monitoring ewentualnych poczynań potencjalnych dżokejów cyberprzestrzeni, czy złośliwego robactwa czyhającego na luki w demonach usług, bo ktoś popełnił mniej lub bardziej umyślnie błąd pozwalający na grzebanie w systemie głębiej niż wypada cywilizowanej aplikacji. Korzystacie z nadzoru takich rzeczy? Czy wychodzicie z założenia, że jak coś takiego naruszy intymność świata wewnętrznego waszej maszyny, to od razu będzie widać następstwa, bo maszyna pluje spamem, albo wszystkie rdzenie kopią bitcoiny? Może ktoś wie jak się takie sprawy organizuje powiedzmy w bankach,  czy innych systemach gdzie potencjalny włam, kogoś przykładowo o inteligencji większej niż chiński botnet i posiadającego 0-daya, którego raczej nie załatają za szybko, jeśli w ogóle. Kogoś kogo działania będą dla właściciela systemu lub jego klientów dotkliwe, ale na tyle subtelne, że bez specjalistycznego nadzoru nad systemem mogą umknąć niezauważone.

[Archi]

Podstawowa zasada, nieistotne czy w banku czy na kebabie u Olesa to limitowanie potencjalnego falloutu. Jeśli zakładasz, że atakujący wbije się np. przez twój serwery pocztowy (dajmy na to tragiczny 0day na postfixa), to robisz wszystko co w twojej mocy żeby wbił się TYLKO na tego postfixa, i nic poza tym.

 

Teraz z kolei sposobów na izolację usług jest od groma, począwszy od chroota i jailkita, poprzez dockera, a na twardej wirtualizacji kvm kończąc, nie wspominając nawet o świetnym jailu z FreeBSD i podobnych narzędziach, które są wykorzystywane. Co jest najlepsze? A to już zależy od twojego widzimisię i tego jak bardzo ufasz lub też nie zabezpieczeniu, które chcesz stosować.

 

Chroot przykładowo jest uznawany za jeden z najgorszych, a z patchem grsecurity stoi na tak wysokim poziomie, że nie znam osoby, któraby z niego dzisiaj wyszła. Działa? Działa, ale to nie znaczy że docker czy kvm jest gorszy, to jest kwestia doboru odpowiedniego narzędzia do potrzeb.

 

Generalnie całość bezpieczeństwa się opiera o możliwie najniższy poziom dostępu dla danej usługi. Serwer pocztowy nie potrzebuje grzebać w bazie danych strony WWW, a php nie potrzebuje mieć dostępu do załączników w firmowej poczcie. Nginx nie musi odpalać nic poza swoimi własnymi procesami-dziećmi, a baza danych nie musi w ogóle akceptować połączeń z innych IP niż serwer php.

 

To są tylko przykłady, bo tak naprawdę nie ma dolnej granicy i wszystko zależy od tego jak bardzo poniesie cię fantazja. Nie ma w 100% bezpiecznej usługi czy systemu, ale są takie, w których nawet hack nie stanowi zagrożenia dla reszty infrastruktury i jest w stanie co najwyżej spowodować problemy z tą jedną konkretną, a o wiele łatwiej naprawić jedną usługę niż cały serwer. Shakujesz mi postfixa, przechwycisz pocztę, w porządku, ale do danych klientów w bazie SQL już się tym nie dostaniesz (zakładając, że nie jestem skończonym kretynem i nie wysyłam haseł do roota e-mailem).

[Pół człowiek pół admin]

59 minut temu, Archi napisał:

Podstawowa zasada, nieistotne czy w banku czy na kebabie u Olesa to limitowanie potencjalnego falloutu. Jeśli zakładasz, że atakujący wbije się np. przez twój serwery pocztowy (dajmy na to tragiczny 0day na postfixa), to robisz wszystko co w twojej mocy żeby wbił się TYLKO na tego postfixa, i nic poza tym.

 

Teraz z kolei sposobów na izolację usług jest od groma, począwszy od chroota i jailkita, poprzez dockera, a na twardej wirtualizacji kvm kończąc, nie wspominając nawet o świetnym jailu z FreeBSD i podobnych narzędziach, które są wykorzystywane. Co jest najlepsze? A to już zależy od twojego widzimisię i tego jak bardzo ufasz lub też nie zabezpieczeniu, które chcesz stosować.

 

Chroot przykładowo jest uznawany za jeden z najgorszych, a z patchem grsecurity stoi na tak wysokim poziomie, że nie znam osoby, któraby z niego dzisiaj wyszła. Działa? Działa, ale to nie znaczy że docker czy kvm jest gorszy, to jest kwestia doboru odpowiedniego narzędzia do potrzeb.

 

Generalnie całość bezpieczeństwa się opiera o możliwie najniższy poziom dostępu dla danej usługi. Serwer pocztowy nie potrzebuje grzebać w bazie danych strony WWW, a php nie potrzebuje mieć dostępu do załączników w firmowej poczcie. Nginx nie musi odpalać nic poza swoimi własnymi procesami-dziećmi, a baza danych nie musi w ogóle akceptować połączeń z innych IP niż serwer php.

 

To są tylko przykłady, bo tak naprawdę nie ma dolnej granicy i wszystko zależy od tego jak bardzo poniesie cię fantazja. Nie ma w 100% bezpiecznej usługi czy systemu, ale są takie, w których nawet hack nie stanowi zagrożenia dla reszty infrastruktury i jest w stanie co najwyżej spowodować problemy z tą jedną konkretną, a o wiele łatwiej naprawić jedną usługę niż cały serwer. Shakujesz mi postfixa, przechwycisz pocztę, w porządku, ale do danych klientów w bazie SQL już się tym nie dostaniesz (zakładając, że nie jestem skończonym kretynem i nie wysyłam haseł do roota e-mailem).

Z większością się tych rzeczy można zgodzić, jakkolwiek średnio odpowiada to na pytanie o monitoring. Plus atak na dostępne ze świata usługi przez eksploitację niedopatrzeń programistycznych, czy projektowych, to tylko jeden z wielu potencjalnych wektorów ataku. Czyli mniej więcej uważasz zabawy z nadzorem nad głębszymi częściami systemu za zbędną zabawę? Pozostają jeszcze celowe złośliwe działania pracowników. OK, można ograniczyć ilość osób z dostępami. Możne też zastosować szantaż na posiadaczu dostępów by wykonał to i owo a potem go "kropnąć" i ukryć zwłoki. Zanim ktoś się zorientuje co się stało, kto wie co mogą takie zmiany zdziałać. Można podmienić hardware w strategicznym punkcie.  Scenariusze można mnożyć im cenniejsze dane i bardziej pomysłowy agresor.

Edytowane 13 Kwietnia 2018 przez Pół człowiek pół admin

[Archi]

Ale co chcesz monitorować? Logi dostępu? Wykonywane akcje? Połączenia? Masz zamiar to czytać? Bo jeśli nie to wnioskuję, że równie dobrze możesz napisać skrypt w bashu w 2 min, który Ci wyśle na e-maila info o tym, że user X się zalogował z IP Y. Tylko co Ci to daje? Będziesz szukał narzędzia, które Ci zawali skrzynkę wszystkimi takimi logowaniami ze wszystkich możliwych usług na wszystkie możliwe sposoby czy jak?

 

A jeśli jednak podchodzisz do sprawy praktycznie to nikt nie będzie siedział i analizował czy przypadkiem ktoś się nie włamał, bo przez ten zmarnowany czas mógłbyś wprowadzić kolejny layer security, chociażby kolejną regułkę iptables, która pozwoli na pakiety SYN wyłącznie na dane, z góry określone porty, co nie pozwoli na wystawienie jakiegoś exploita na nowy port i stworzenia serwera C&C.

 

Logi prowadzisz po to, żeby w momencie ew. włamania albo fuckupu wiedzieć co się stało, gdzie i jak, a nie po to żeby je czytać, bo jak chcesz je czytać to możesz sobie grepem w basha wrzucić, nie wiem tylko po co. Monitorować możesz wiele rzeczy, ale jeśli coś monitorujesz to z definicji to coś jest przede wszystkim możliwe, a podstawowym założeniem w bezpieczeństwie jest to, że włamanie nie jest możliwe, poprzez dołożenie wszelkich starań, żeby to zdanie było jak najbardziej zgodne z rzeczywistością (co nigdy oczywiście nie ma miejsca, ale można mocno próbować).

 

Ja wolę jednak łatanie dziur, a nie monitorowanie czy ktoś przypadkiem je wykorzystuje. Przy dobrze skonfigurowanym systemie atakujący nie odpali żadnego niepożądanego procesu, nie wrzuci żadnego podejrzanego pliku kopiącego bitcoiny, ani nie dotrze do wrażliwych danych. Przy takim systemie masz o wiele większą szansę na załatanie dziury znalezionej zupełnie przypadkiem i jednocześnie odcięcia atakującego niż "monitorowanie" całego ruchu sieciowego i "znalezienie" takiego intruza, zakładając oczywiście, że jesteś na pewnym poziomie wiedzy i bezpieczeństwa, bo jak monitorowanie u Ciebie znaczy grep "session opened" /var/log/auth.log to rozmawiamy jednak w zupełnie różnych kategoriach.

[Piotr GRD]

Sam nigdy tego nie stosowałem, ale pewien znajomy miał kiedyś problem z hostingiem współdzielonym od - bodajże - GoDaddy, na którym co rusz forum oparte chyba o SMF było automatycznie hakowane i wklejany był niechciany kod. Akurat wtedy nie był to problem ani z samym SMF ani z niczym innym na koncie hostingowym znajomego, był on pewien swego, choć obsługa hostingu twierdziła, że to wina klienta i jego skryptów. Po kilku tygodniach wyszło, że to jednak problem hostingu, wielu klientów miało podobne problemy, ale gigant oczywiście wyciszył sprawę.

 

W międzyczasie, gdy przez te kilka tygodni forum tak co kilka/kilkanaście godzin było modyfikowane, znajomy napisał sobie skrypt odpalany regularnie przez cronjob porównujący hash istotnych plików i w razie wykrycia zmian przywracający z archiwum ich poprzednią prawidłową wersję.

 

To wydaje mi się najprostsze rozwiązanie w celu uniknięcia długotrwałego nie wykrycia zmian - regularne sprawdzanie zmian w istotnych plikach/katalogach, a w razie ich wykrycia albo automatyczne przywrócenie poprzedniej wersji, albo sygnał puszczony do admina. Oczywiście nie sprawdzi się za bardzo, gdy zwyczajne, autoryzowane zmiany wykonywane są dość często przez wiele uprawnionych do tego osób, ale tam gdzie autoryzowane zmiany są rzadkie - jak najbardziej.

[Suspect]

Polecam Ci zainteresować się AppArmor. Nie tylko wzmocni bezpieczeństwo Twojego systemu ale też umożliwi logowanie wszelkich podejrzanych, niespodziewanych działań na Twoim serwerze. W skrócie AppArmor pozwoli Ci na ograniczenie dostępu dla poszczególnych aplikacji jedynie do wybranych plików Twojego systemu. Tworzy się w tym celu dedykowane profile pod poszczególne aplikacje. Jeżeli przykładowo z poziomu serwera WWW nastąpiłaby próba dostępu do /tmp a Ty na taki dostęp nie zezwoliłeś, takie zachowanie może być logowane. Na podstawie analizy logów AppArmor, jesteś w stanie określić czy na Twoim serwerze miały miejsce jakieś podejrzane działania.

[Archi]

O, hash plików, który Piotr GRD opisał wyżej jest jedną z lepszych metod, tyle tylko że zamiast robić to na około to zrobiłbym albo mount w trybie readonly, albo chattr +i.