Nasze centrum cyberobrony odpowiada za bezpieczeństwo infrastruktury internetowej klienta i odpiera ataki na strony klientów. Aby chronić się przed atakami, używamy zapór sieciowych aplikacji internetowych FortiWeb (WAF). Ale nawet najfajniejszy WAF nie jest panaceum i nie chroni „od razu po wyjęciu z pudełka” przed atakami ukierunkowanymi.
Dlatego oprócz WAF używamy . Pomaga zebrać wszystkie zdarzenia w jednym miejscu, gromadzi statystyki, wizualizuje je i pozwala w porę dostrzec ukierunkowany atak.
Dziś opowiem Wam szerzej jak przeszliśmy przez choinkę z WAF-em i co z tego wyszło.
Historia jednego ataku: jak wszystko działało przed przejściem na ELK
W naszej chmurze klient wdrożył aplikację stojącą za naszym WAF-em. Od 10 000 do 100 000 użytkowników dziennie podłączonych do serwisu, liczba połączeń sięgała 20 milionów dziennie. Spośród nich 3–5 użytkowników było intruzami i próbowało włamać się na stronę.
Zwykła forma brutalnej siły z jednego adresu IP została dość łatwo zablokowana przez FortiWeb. Liczba wejść na stronę na minutę była wyższa niż w przypadku legalnych użytkowników. Po prostu ustaliliśmy progi aktywności z jednego adresu i odeprzeliśmy atak.
Znacznie trudniej jest poradzić sobie z „powolnymi atakami”, gdy napastnicy działają powoli i udają zwykłych klientów. Używają wielu unikalnych adresów IP. Taka aktywność nie wyglądała dla WAF na masową, brutalną siłę, trudniej było ją wyśledzić automatycznie. Istniało również ryzyko zablokowania zwykłych użytkowników. Szukaliśmy innych oznak ataku i stworzyliśmy politykę automatycznego blokowania adresów IP na podstawie tego znaku. Na przykład wiele nielegalnych sesji miało wspólne pola w nagłówkach żądań http. Często trzeba było szukać takich pól ręcznie w dziennikach zdarzeń FortiWeb.
Zrobiło się długo i niewygodnie. W standardowej funkcjonalności FortiWeb zdarzenia zapisywane są tekstowo w 3 różnych logach: wykrytych atakach, informacjach o żądaniach oraz komunikatach systemowych o działaniu WAF. W ciągu minuty mogą nastąpić dziesiątki, a nawet setki ataków.
Niewiele, ale musisz ręcznie przejść przez kilka dzienników i iterować po wielu liniach:
W dzienniku ataków widzimy adresy użytkowników i charakter działania.
Nie wystarczy po prostu zeskanować tabelę logów. Aby znaleźć najciekawsze i najbardziej przydatne informacje na temat natury ataku, musisz przyjrzeć się konkretnemu zdarzeniu:
Podświetlone pola pomagają wykryć „powolny atak”. Źródło: zrzut ekranu z .
Cóż, główny problem polega na tym, że tylko specjalista FortiWeb może to rozgryźć. Jeśli w godzinach pracy nadal moglibyśmy śledzić podejrzaną aktywność w czasie rzeczywistym, dochodzenie w sprawie incydentów nocnych mogłoby się opóźnić. Kiedy z jakiegoś powodu zasady FortiWeb nie zadziałały, dyżurujący inżynierowie nocnej zmiany nie mogli ocenić sytuacji bez dostępu do WAF i obudzili specjalistę FortiWeb. Przez kilka godzin przeglądaliśmy kłody i znaleźliśmy moment ataku.
Przy takiej ilości informacji trudno jest na pierwszy rzut oka zrozumieć ogólny obraz sytuacji i działać proaktywnie. Następnie postanowiliśmy zebrać dane w jednym miejscu, aby wszystko przeanalizować w formie wizualnej, znaleźć początek ataku, określić jego kierunek i sposób blokowania.
Co zostało wybrane
W pierwszej kolejności przyjrzeliśmy się rozwiązaniom już stosowanym, aby niepotrzebnie nie mnożyć bytów.
Jedną z pierwszych opcji była Nagiosktóre używamy do monitorowania , , alarmy awaryjne. Ochroniarze używają go również do powiadamiania obsługi w przypadku podejrzanego ruchu, ale nie wie, jak zebrać rozproszone dzienniki i dlatego znika.
Istniała opcja agregowania wszystkiego MySQL i PostgreSQL lub inna relacyjna baza danych. Aby jednak wyciągnąć dane, konieczne było zaprojektowanie aplikacji.
Jako zbieracz kłód w naszej firmie również korzystają Analizator Forti z Fortineta. Ale w tym przypadku również nie pasował. Po pierwsze, bardziej wyostrzona jest praca z zaporą ogniową FortiGate. Po drugie, brakowało wielu ustawień, a interakcja z nimi wymagała doskonałej znajomości zapytań SQL. I po trzecie, jego zastosowanie podniosłoby koszt usługi dla klienta.
W ten sposób doszliśmy do otwartego oprogramowania w twarz ŁOŚ.
Dlaczego wybrać ELK
ELK to zestaw programów typu open source:
- Elasticsearch - baza szeregów czasowych, która właśnie została stworzona do pracy z dużą ilością tekstu;
- Logstash – mechanizm gromadzenia danych umożliwiający konwersję logów do żądanego formatu;
- Kibana - dobry wizualizator, a także dość przyjazny interfejs do zarządzania Elasticsearch. Można go używać do tworzenia harmonogramów, które inżynierowie dyżurni mogą monitorować w nocy.
Próg wejścia dla ELK jest niski. Wszystkie podstawowe funkcje są bezpłatne. Czego jeszcze potrzeba do szczęścia.
Jak to wszystko połączyłeś w jeden system?
Utworzono indeksy i pozostawiono tylko niezbędne informacje. Załadowaliśmy wszystkie trzy logi FortiWEB do ELK - wynikiem były indeksy. Są to pliki zawierające wszystkie zebrane logi za okres np. jeden dzień. Gdybyśmy od razu je zwizualizowali, zobaczylibyśmy jedynie dynamikę ataków. Aby uzyskać szczegółowe informacje, musisz „wpaść” w każdy atak i przyjrzeć się konkretnym polom.
Zdaliśmy sobie sprawę, że najpierw musimy skonfigurować analizę informacji nieustrukturyzowanych. Wzięliśmy długie pola jako ciągi znaków, takie jak „Wiadomość” i „URL”, i przeanalizowaliśmy je, aby uzyskać więcej informacji na potrzeby podejmowania decyzji.
Na przykład za pomocą parsowania osobno usunęliśmy lokalizację użytkownika. Pomogło to natychmiast uwypuklić ataki z zagranicy na witryny rosyjskich użytkowników. Blokując wszystkie połączenia z innych krajów, 2-krotnie zmniejszyliśmy liczbę ataków i mogliśmy łatwo poradzić sobie z atakami wewnątrz Rosji.
Po przeanalizowaniu zaczęli szukać informacji, które należy przechowywać i wizualizować. Pozostawienie wszystkiego w logu było niewłaściwe: rozmiar jednego indeksu był duży - 7 GB. Przetwarzanie pliku przez ELK trwało długo. Jednak nie wszystkie informacje okazały się przydatne. Coś się zdublowało i zajmowało dodatkową przestrzeń - trzeba było zoptymalizować.
Na początku po prostu przejrzeliśmy indeks i usunęliśmy niepotrzebne zdarzenia. Okazało się to jeszcze bardziej niewygodne i dłuższe niż praca z logami w samym FortiWeb. Jedynym plusem „choinki” na tym etapie jest to, że udało nam się zwizualizować duży okres czasu na jednym ekranie.
Nie rozpaczaliśmy, nadal jedliśmy kaktusa i badaliśmy ELK i wierzyliśmy, że uda nam się wydobyć niezbędne informacje. Po oczyszczeniu indeksów zaczęliśmy wizualizować co jest. Dotarliśmy więc do dużych dashboardów. Wrzuciliśmy widżety - wizualnie i elegancko, prawdziwa ЁLKa!
Uchwycono moment ataku. Teraz należało zrozumieć jak na wykresie wygląda początek ataku. Aby to wykryć, sprawdziliśmy odpowiedzi serwera skierowane do użytkownika (kody zwrotne). Nas interesowały odpowiedzi serwerów z takimi kodami (rc):
Kod (rc)
Nazwa
Opis
0
DROP
Żądanie do serwera jest zablokowane
200
Ok
Żądanie przetworzone pomyślnie
400
Zła prośba
Zła prośba
403
Zabroniony
Autoryzacja odrzucona
500
Internal Server Error
Usługa jest niedostępna
Jeśli ktoś zaczął atakować witrynę, proporcja kodów uległa zmianie:
- Jeśli było więcej błędnych żądań z kodem 400 i taką samą liczbę normalnych żądań z kodem 200, oznacza to, że ktoś próbował zhakować witrynę.
- Jeśli w tym samym czasie wzrosła także liczba żądań z kodem 0, to politycy FortiWeb również „zobaczyli” atak i zastosowali wobec niego blokady.
- Jeśli zwiększy się liczba wiadomości z kodem 500, to strona nie będzie dostępna dla tych adresów IP - to także rodzaj blokowania.
W trzecim miesiącu utworzyliśmy pulpit nawigacyjny do śledzenia tej aktywności.
Aby nie monitorować wszystkiego ręcznie, ustawiliśmy integrację z Nagiosem, który w określonych odstępach czasu odpytywał ELK. Jeżeli odnotował osiągnięcie wartości progowych kodami, wysyłał powiadomienie do dyżurnych o podejrzanej aktywności.
Połączone 4 wykresy w systemie monitorowania. Teraz należało zobaczyć na wykresach moment, w którym atak nie zostaje zablokowany i konieczna jest interwencja inżyniera. Na 4 różnych wykresach nasze oko było zamazane. Dlatego połączyliśmy wykresy i zaczęliśmy obserwować wszystko na jednym ekranie.
Na monitoringu obserwowaliśmy, jak zmieniają się wykresy o różnych kolorach. Wybuch czerwieni wskazywał, że rozpoczął się atak, natomiast pomarańczowe i niebieskie wykresy przedstawiały reakcję FortiWeb:
Tutaj wszystko jest w porządku: nastąpił wzrost „czerwonej” aktywności, ale FortiWeb sobie poradził, a harmonogram ataków spełzł na niczym.
Narysowaliśmy też dla siebie przykładowy wykres wymagający interwencji:
Tutaj widzimy, że FortiWeb zwiększył aktywność, ale czerwony wykres ataku nie spadł. Musisz zmienić ustawienia WAF.
Prostsze stało się także prowadzenie dochodzeń w sprawie incydentów nocnych. Wykres od razu pokazuje moment, w którym należy przystąpić do obrony obiektu.
Tak się czasem dzieje w nocy. Czerwony wykres - rozpoczął się atak. Niebieski — aktywność FortiWeb. Atak nie został całkowicie zablokowany, musieliśmy interweniować.
Gdzie idziemy
Teraz szkolimy administratorów dyżurnych do współpracy z ELK. Asystenci uczą się oceniać sytuację na dashboardzie i podejmować decyzję: czas eskalować sprawę do specjalisty FortiWeb, w przeciwnym razie zasady na WAF wystarczą, aby automatycznie odeprzeć atak. W ten sposób odciążamy inżynierów bezpieczeństwa w nocy i dzielimy się rolami wsparcia na poziomie systemu. Dostęp do FortiWeb ma wyłącznie centrum cyberobrony i tylko ono wprowadza zmiany w ustawieniach WAF, gdy są one pilnie potrzebne.
Pracujemy także nad raportowaniem dla klientów. Planujemy, że dane dotyczące dynamiki pracy WAF będą dostępne na koncie osobistym klienta. ELK rozjaśni sytuację bez konieczności odwoływania się do samej WAF.
Jeśli klient chce monitorować swoją ochronę w czasie rzeczywistym, z pomocą przyjdzie także ELK. Nie możemy oddać dostępu do WAF, gdyż ingerencja klienta w pracę może mieć wpływ na resztę. Ale możesz wziąć osobny ELK i dać go do „pobawienia się”.
Oto scenariusze wykorzystania choinki, które ostatnio zgromadziliśmy. Podziel się swoimi przemyśleniami na ten temat i nie zapomnij aby uniknąć wycieków baz danych.
Źródło: www.habr.com