Security Onion – Monitoring Bezpieczeństwa Sieci

Security Onion to bazująca na Ubuntu dystrybucja linuksa służąca do monitorowania bezpieczeństwa sieci. W jej skład wchodzą narzędzia służące do gromadzenia i analizowania danych oraz wizualizacji zagrożeń. W tym artykule opiszemy w jaki sposób uruchomić własną stację monitorowania sieci na bazie Security Onion.

Uwaga – dostępny jest też nowszy tekst pt. Security Onion 2 – open source SIEM / SOC. Mimo wszystko sugerujemy najpierw zapoznać się z poniższym opisem, ponieważ stanowi on dobre wprowadzenie do tematu monitorowania bezpieczeństwa.

Wymagania

Security Onion może nam posłużyć do monitorowania nawet dużego środowiska sieciowego. W takim wypadku będziemy jednak musieli stworzyć infrastrukturę składającą się z serwera będącego centralnym punktem gromadzenia i wizualizowania danych oraz szeregu sond analizujących ruch w różnych miejscach sieci z użyciem m.in. IDS-a. Zanim przejdziemy do tak zaawansowanej konfiguracji warto byłoby przyjrzeć się możliwościom poszczególnych narzędzi na jakimś prostszym przykładzie. W tym celu twórcy Security Onion przygotowali specjalny tryb instalacji: 'evaluation’ służący do monitorowania niewielkiego środowiska i skupiający wszystkie wymagane do tego usługi na jednym serwerze. Instalacja taka sprawdzi się w domu lub małej firmie, ale nawet do tak niewielkiego środowiska zalecana jest stacja dysponująca 8GB pamięci RAM, 2 lub 4 rdzeniami procesora oraz minimum 50GB dyskiem.

Konfiguracja sieci

Nasza stacja monitorująca wyposażona musi być minimum w dwa interfejsy sieciowe. Jeden z nich służył będzie do zarządzania oraz zbierania logów systemowych, drugi do monitorowania ruchu sieciowego przy użyciu sondy IDS. Jeżeli chcemy monitorować ruch z więcej niż jednego segmentu sieci, potrzebować będziemy więcej interfejsów. Ponadto zadbać musimy o to, aby na karcie sieciowej, która ma analizować ruch sieciowy pojawił się ruch z całego segmentu sieci. Pamiętajmy, że domyślnie switche przekazują na dany port tylko ruch kierowany do dostępnych na tym porcie urządzeń lub broadcasty. Jeżeli chcemy analizować ruch wymieniany pomiędzy innymi urządzeniami w sieci, musimy ustawić kartę sieciową w tryb promiscuous (o to zadba sam instalator) oraz skierować na port w switchu, do którego podepniemy naszą stację ruch z całego switcha. Do tego będzie nam potrzebny switch zarządzalny oferujący możliwość kopiowania całego ruchu na wskazany port. Funkcjonalność ta u różnych producentów nazywana jest różnie, np. 'port monitor’, 'port mirroring’, 'span’.

Jeżeli nie dysponujemy takim switchem lub nie chcemy go obciążać, a chcielibyśmy np. monitorować cały ruch wymieniany pomiędzy siecią lokalną a Internetem lub innym segmentem sieci, możemy posłużyć się urządzeniem typu TAP. TAPa w dużym uproszczeniu możemy sobie wyobrazić jako „podsłuch” wpinany pomiędzy dwa urządzenia sieciowe, który cały wymieniany przez niego ruch wysyła dodatkowo na trzeci port podłączony właśnie do urządzenia monitorującego. Niestety urządzenia tego typu nie są łatwo dostępne i nie należą do tanich. W domowych zastosowaniach lepiej więc sprawdzi się np. taki router Mikrotika z wbudowanym switchem, który posiada funkcję port monitora.

Instalacja

Najnowszą wersję instalacyjną w formie obrazu ISO znajdziecie tutaj. Sama instalacja systemu jest dość intuicyjna. Na etapie instalacji nie są dokonywane żadne zaawansowane ustawienia poza nazwą i hasłem użytkownika. Po zakończeniu tego etapu i zalogowaniu się do systemu, na pulpicie widoczna będzie ikona „Setup”, której uruchomienie przeprowadzi nas przez proces konfiguracji w dwóch etapach. W pierwszym etapie nastąpi konfiguracja sieci. Zwrócić tutaj musimy uwagę na następujące kwestie:

• Interfejs zarządzający powinniśmy skonfigurować ze statycznym adresem IP, ponieważ z nim powiązane będą usługi umożliwiające nam m.in. dostęp do interfejsu webowego.
• Interfejs służący do analizy (sniffing interface) powinien być interfejsem szybkim – min. 1Gbit, gdyż trafiać będzie do niego spora ilość ruchu. Temu interfejsowi nie przypisujemy żadnej konfiguracji na poziomie IP.

Po konfiguracji sieci nastąpi restart serwera, a po jego uruchomieniu ponownie poprzez ikonę „Setup” z pulpitu wrócić musimy do kreatora instalacji. Tym razem zostaniemy zapytani o tryb instalacji „production” lub „evaluation”. Wybieramy tryb „evaluation” i reszta konfiguracji polega na klikaniu 'OK’ oraz zdefiniowaniu nazwy użytkownika i hasła, którym będziemy się uwierzytelniać przy dostępie do narzędzi analitycznych.

Możliwe problemy

Sporym problemem może się okazać próba uruchomienia Security Onion jako maszyny wirtualnej na Windowsie 10. O ile sam system zainstaluje się i uruchomi bez problemu, o tyle problematycznym będzie zmuszenie interfejsu sniffującego do prawidłowego działania w trybie promiscuous. Aby z maszyny wirtualnej widzieć cały ruch sieciowy na określonym interfejsie fizycznym musimy zarówno interfejs fizyczny, jak i wirtualny ustawić w tryb promiscuous oraz na poziomie maszyny wirtualnej wybrać tryb pracy interfejsu jako bridged. Niestety w mojej testowej konfiguracji gdzie jako hosta użyłem Windowsa 10, najpierw z Virtualboxem, a poźniej z VMware Workstation, nie udało mi się uzyskać pożądanego efektu. Za każdym razem na poziomie hosta był widziany cały ruch sieciowy, natomiast na poziomie maszyny wirtualnej tylko ruch lokalny (do testów używałem Wiresharka). W Internecie sporo osób sygnalizowało podobne problemy. Jednym z sugerowanych rozwiązań było zmostkowanie interfejsu fizycznego pod windowsem z interfejsem sieci wewnętrznej (host only) środowiska wirtualnego i wymuszenie na całym bridge’u trybu promiscuous przy użyciu polecenia „netsh bridge set adapter X force compatmode=enable”, po czym przełączenie w maszynie wirtualnej karty sieciowej z bridge’a do sieci wewnętrznej. Niestety to również nie pomogło – gdzieś pojawiły się sugestie, że zadziała to jedynie na systemach Windows Server.

Ostatecznie poddałem się z taką konfiguracją i wymyśliłem inne rozwiązanie – podłączenie do komputera z Windowsem karty sieciowej na USB i przekazanie jej obsługi do maszyny wirtualnej. Ta konfiguracja na Virtualboxie kończyła się kilkukrotnie blue screenem, na VMware Workstation jednak zadziałała. Pojawił się jednak inny problem – karta Realteka na USB nie chciała współpracować z modułem jądra o nazwie pf_ring, z którego korzysta domyślnie Snort (jeden z dwóch dostępnych w Security Onion IDS-ów). Musiałem więc powtórzyć instalację w trybie zaawansowanym zmieniając domyślnego Snorta na Surricatę, która z pf_ring-u nie korzysta.

Jeżeli więc rozważacie uruchomienie Security Onion jako maszyny wirtualnej, sugeruję użycie jako hosta systemu serwerowego, a najlepiej Linuksa lub ESX-a. Wszelkich problemów unikniecie natomiast na pewno instalując Security Onion bezpośrednio na maszynie fizycznej.

Przegląd zdarzeń z systemów IDS

Jeżeli problemów z wirtualizacją udało nam się uniknąć, to już po kilku minutach od instalacji skorzystać możemy z pierwszych narzędzi. Po zalogowaniu na pulpicie dostępne będą m.in. dwie ikony: Squil oraz Squert. Obie aplikacje służą do przeglądania alertów z IDS-ów. I tutaj warto wspomnieć, że Security Onion posiada dwie kategorie sond IDS:

• NIDS (Network IDS) w postaci Snorta lub Surricaty (domyślnie jest to Snort, ale w zaawansowanych konfiguracjach lepiej sprawdzi się Surricata, która ze względu na obsługę wielowątkowości zapewnia lepszą wydajność). Jest to typowy IDS sieciowy bazujący na sygnaturach i analizujący przechwytywane z sieci pakiety.
• HIDS (Host IDS) w postaci systemu Wazuh. Wazuh jest nieco rozwiniętym i  nowocześniejszym forkiem znanego OSSEC-a. Jest to IDS zbierający dane z systemu (stąd Host IDS) i analizujący m.in. logi oraz inegralność plików i rejestru systemowego.

Po domyślnej konfiguracji pierwszy z IDS-ów gromadzi i analizuje dane ze wskazanego interfejsu sieciowego, drugi natomiast z samego systemu Security Onion (ale docelowo będziemy do niego kierować również zdarzenia z innych systemów). Wspomniana wcześniej aplikacja Sguil umożliwia nam przeglądanie obu typów zdarzeń:

Zdarzenia z HIDS-a Wazuh (oznaczone jako OSSEC) to np.:

• Utworzenie nowego użytkownika lub grupy w systemie
• Przejście interfejsu sieciowego w tryb promiscuous
• Otwarcie nowego portu tcp/udp w systemie

Jak widać, z punktu widzenia bezpieczeństwa są to zdarzenia, które zdecydowanie warto monitorować. Wazuh/OSSEC potrafi też m.in. wykrywać rootkity, nieudane próby logowania, modyfikacje plików systemowych, instalacje pakietów i wiele, wiele innych. Z NIDS-a (w tym wypadku Surricata) mamy natomiast na powyższym zrzucie ekranu informacje o:

• możliwym wystąpieniu ataku DDOS z użyciem usługi NTP
• zdarzeniu „GPL ATTACK_RESPONSE id check returned root”, które jest efektem otwarcia strony testmyids.com, zwracającej testową sygnaturę dla systemów IDS. Każdy szanujący się IDS powinien rozpoznać ją jako zagrożenie – jest to odpowiednik testowej sygnatury EICAR dla systemów antywirusowych lub GTUBE dla systemów antyspamowych.

Kolejnym interfejsem pozwalającym na przeglądanie zdarzeń z IDS-ów jest webowy Squert. Jego przewagą jest możliwość grupowania zdarzeń tego samego typu oraz generowanie podsumowań prezentujących przepływ danych pomiędzy poszczególnymi adresami IP:

Ten artykuł dotyczył starszej wersji systemu Security Onion. Koniecznie zapoznaj się też z jego nową odsłoną, którą prezentujemy w tekście pt. „Security Onion 2 – open source SIEM / SOC„.

Obserwuj

Obserwuj