Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
OSSEC czyli darmowy HIDS
Wstęp
OSSEC jest kompletną platformą do monitorowania stanu systemów operacyjnych w Twojej sieci oferującą funkcjonalności HIDS, SIEM, monitorowania logów, wykrywania rootkitów oraz sprawdzania integralności plików systemowych.
Działa pod wszystkimi popularnymi systemami – Windows, Linux, Mac OS X, Solaris, pod systemami z rodziny BSD i innymi.
Na platformę OSSEC składają się dwa główne komponenty:
- Manager – centralny element platformy, to tutaj przechowywane są bazy danych z informacjami od agentów na temat zdarzeń w ich systemach, integralności plików oraz logów systemowych. Tutaj także znajduje się cała konfiguracja agentów, dzięki czemu możliwe jest centralne zarządzanie całą infrastrukturą.
- Agent – komponent działający w systemie koocowym, który zajmuje się monitorowaniem logów, sprawdzaniem integralności plików i przekazywaniem wszelkich skonfigurowanych zdarzeń do komponentu managera.
Poza tym OSSEC oferuje także wsparcie dla środowisk, w których nie można zainstalować agenta, jak również dla firewalli i routerów najpopularniejszych firm (poprzez syslog, SNMP, WMI etc.).
Instalacja Managera
1. Instalacja managera OSSEC w systemach unixowych:
1. Należy pobrać i rozpakować paczki ze strony OSSEC:
wget http://www.ossec.net/files/ossec-hids-latest.tar.gz
tar -zxvf ossec-hids*.tar.gz
2. Uruchomienia skryptu install.sh z katalogu, do którego rozpakowaliśmy paczkę:
cd ossec-hids-*
./install.sh
3. Otwarcia portu 1514 UDP na firewallu:
iptables -A INPUT -p udp –dport 1514 -j ACCEPT
4. Uruchomienia usługi OSSEC:
/var/ossec/bin/ossec-control start
2. Instalacja agenta w systemie Windows
Pobieramy plik instalacyjny agenta OSSEC dla Windows.
Po pobraniu instalacja przebiega w standardowy sposób i kończy się uruchomieniem agenta:
Aby jednak agent mógł współpracować z managerem OSSEC, należy dodać go do bazy agentów.
3. Dodawanie agenta do bazy agentów
Aby dodać agenta do bazy agentów na systemie, na którym zainstalowany jest komponent managera OSSEC, należy:
1. Należy Uruchomić program manage_agents (znajdujący się w /var/ossec/bin).
2. Z menu wybrać opcję Add an agent.
3. Podać nazwę dla nowego agenta.
4. Podać IP Agenta (lub jego maskę podsieci w notacji CIDR, jeżeli używane jest DHCP).
5. Zatwierdzić ID nowego agenta.
6. Potwierdzić poprawność konfiguracji.
Następnie, nie wychodząc z programu manage_agents, należy z menu głównego wybrać opcję Extract key for an agent:
Zapisujemy klucz, gdyż będzie on potrzebny za chwilę do konfiguracji agenta.
Po dodaniu wszystkich agentów należy zrestartować usługę managera, wydając komendę:
/etc/init.d/ossec restart
4. Konfiguracja agenta Windows
Konfiguracja agenta Windows sprowadza się do wpisania adresu IP managera oraz klucza agenta uzyskanego we wcześniejszym kroku. Należy zadbać, aby ten sam klucz nie powtarzał się u dwu agentów – do poprawnego działania każdy agent musi posiadać własny klucz.
Następnie w programie agenta wybieramy z menu Manage komendę Start OSSEC. W tym momencie agent startuje i łączy się z serwerem.
Aby zweryfikować poprawność połączenia z agentem na komputerze managera należy wydać komendę:
/var/ossec/bin/agent_control -l
W jej wyniku otrzymamy listę agentów wraz z ich stanem:
Przy użyciu programu agent_control możemy także dowiedzieć się więcej o systemie, na którym dany agent jest zainstalowany (opcja -i <id agenta>), bądź też wymusić na agentach sprawdzanie integralności plików (opcja -r).
Opcjonalnie do wylistowania agentów można także użyć narzędzia /var/ossec/bin/list_agents.
Monitorowanie logów systemowych
Jak wspomniałem wcześniej, OSSEC pozwala na monitorowanie logów, ich przesyłanie do managera i informowanie o zagrożeniach na komputerach, na których są zainstalowane agenty. Całość tego procesu odbywa się w czasie rzeczywistym.
W przypadku systemów Windows, jak i większości dystrybucji Linuxa, nie ma potrzeby dodatkowego konfigurowania agenta do monitorowania logów, gdyż podane w konfiguracji ścieżki są zazwyczaj poprawne.
Gdyby jednak tak nie było, to lokalizację logów można poprawić, edytując plik ossec.conf na agencie. Za lokalizację logów odpowiadają sekcje localfile, przykładowo dla Windows mamy:
<localfile> <location>Application</location> <log_format>eventlog</log_format> </localfile> <localfile> <location>Security</location> <log_format>eventlog</log_format> </localfile> <localfile> <location>System</location> <log_format>eventlog</log_format> </localfile>
Natomiast domyślnie w Linuxie mamy skonfigurowane monitorowanie następujących logów:
<localfile> <log_format>syslog</log_format> <location>/var/log/messages</location> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/auth.log</location> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/syslog</location> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/mail.info</location> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/dpkg.log</location> </localfile> <localfile> <log_format>apache</log_format> <location>/var/log/apache2/error.log</location> </localfile> <localfile> <log_format>apache</log_format> <location>/var/log/apache2/access.log</location> </localfile>
Po zweryfikowaniu konfiguracji agenta, możemy sprawdzić, czy mechanizm zbierania logów i generowania na ich podstawie alertów działa poprawnie.
W tym celu na stacji z Windows próbujemy się zalogować lub też próbujemy odpalić dowolny program jako użytkownik administrator, celowo podając błędne hasło. Próba ta oczywiście nie powiedzie się, a w logach zostanie informacja o nieudanym logowaniu.
W celu sprawdzenia na managerze, czy informacja z logów dotarła, została przetworzona oraz czy został wygenerowany alert wyświetlamy zawartość pliku /var/ossec/logs/alerts/alerts.log:
Jak widzimy na załączonym zrzucie ekranowym – został wygenerowany alert zawierający informacje o nieudanej próbie uwierzytelnienia na komputerze LabClient01, na którym jest zainstalowany agent.
Rootcheck
Rootcheck jest modułem agenta OSSEC, który odpowiada za wykrywanie rootkitów w systemie, na którym ten agent jest zainstalowany. Domyślnie skan systemu pod kątem rootkitów jest wykonywany co 2 godziny.
Detekcja rootkitów przez rootcheck odbywa się poprzez wykonanie serii wywołań systemowych stats, fopen i opendir na podstawie informacji z plików rootkit_files.txt oraz na podstawie sygnatur z pliku rootkit_trojans.txt.
W systemach unixowych wykonywany jest dodatkowo skan katalogu /devpod kątem występowania w nim plików niebędących urządzeniami oraz całego systemu plików pod kątem błędnych uprawnień.
Poza analizą systemu plików mechanizm rootcheck szuka także ukrytych procesów oraz portów sieciowych.
Syscheck
Syscheck jest modułem agenta OSSEC odpowiedzialnym za monitorowanie integralności plików i rejestru. Integralność jest sprawdzana domyślnie co 6 godzin i polega na wyliczeniu sum MD5/SHA1 z wybranych plików lub kluczy rejestru (w systemach Windows). Sumy te są następnie przez agenta przesyłane do managera, który porównuje je z sumami ze swojej bazy i w przypadku wystąpienia rozbieżności, generuje alert.
Mechanizmu syscheck konfigurujemy, edytując plik ossec.conf na agencie w sekcji syscheck.
Przykładowo, jeśli chcemy audytować konfigurację katalogu C:\Important, do konfiguracji agenta należy dopisać:
<syscheck> <directories check_all="yes">C:\Important</directories> </syscheck> </syscheck>
Opcja check_all sprawi, że weryfikowane będą nie tylko skrótu MD5 i SHA1, ale także właściciel pliku oraz uprawnienia do pliku.
Inną opcją, jaką można zastosować do sekcji directorie jest opcja report_changes. Jej ustawienie spowoduje, że poza informacją o zmianie w pliku do managera, zostaną także wysłane zmiany, jakie wystąpiły w pliku.
Aby przetestować działanie mechanizmu syscheck na komputerze z agentem, tworzymy katalog C:\Important i umieszczamy w nim dowolny plik tekstowy o dowolnej treści.
Następnie do ossec.confna agencie, w sekcji syscheck dopisujemy linijkę:
<directories check_all="yes">C:\Important</directories>
Restartujemy agenta wybierając z menu Manage polecenie Restart.
Kolejnym krokiem jest wywołanie na systemie managera polecenia: /var/ossec/bin/agent_control -r -a
Spowoduje ono wymuszenie sprawdzania integralności plików na wszystkich agentach.
W tym momencie zmieniamy zawartość wcześniej utworzonego pliku na agencie oraz ponownie wywołujemy komendę agent_control -r -a (robimy to, aby wymusić sprawdzanie i nie czekać do następnego uruchomienia syscheck wg harmonogramu).
Po chwili, gdy syscheck zakończy skanowanie plików, w pliku /var/ossec/logs/alerts/alerts.log na komputerze managera pojawi się informacja o naruszeniu integralności plików:
Na powyższym zrzucie został także zaprezentowany wynik użycia polecenia: syscheck_control -i 001.
Polecenie to powoduje wyświetlenie informacji o czasie i pliku, który został zmieniony na danym agencie (001 to ID agenta).
Podsumowanie
Jak zostało pokazane w tym artykule, konfiguracja OSSEC nie jest skomplikowana, natomiast korzyści dla bezpieczeństwa infrastruktury w postaci centralnego zarządzania i monitorowania hostów w sieci są na tyle znaczące, że warto rozważyć wdrożenie OSSEC we własnej sieci.
–Łukasz Tomaszkiewicz, (tomaszkiewicz <at> algotronic.pl)
Wlasnie bede testowal u siebie.
Macie bardzo ciekawe artykuly, pozdrawiam.
:)
Generalnie też zaletą OSSECa jest to, że dość sprawnie się całość instaluje -> szybko można przetestować w działaniu.
–ms
Ale Super !
Serwer bez problemu zainstalowany ale agent wywala przy instalacji
sha_locl.h:346: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type!
make[2]: *** [sha1] Error 1
make[1]: *** [os_crypto] Error 2
Error Making os_crypto
make: *** [all] Error 1
Błąd 0x5.
Błąd kompilacji. Nie można zakończyć instalacji.
Ktoś ma jakiś pomysł?
Szymon, na Mac OS X’ie masz ten komunikat? ;)
http://apt0.org/2012/10/01/install-ossec-on-os-x-mountain-lion-10-8-how-to/
Ciekawi mnie dlaczego plik ossec.conf, jak i kilka pozostałych plików konfiguracyjnych, mają ustawione atrybuty tylko do odczytu (r–r—–). Na moje oko nie zwiększa to w żaden sposób bezpieczeństwa, a jedynie utrudnia edycję tych plików (trzeba przed każdą edycją dawać sobie uprawnienia do zapisu). Ale może tkwi w tym jakiś głębszy sens.
Fajna jest opcja „active response” blokująca IP intruzów na określony czas poprzez automatyczne dodawanie wpisów w pliku hosts.deny
Jeśli z głową wcześniej skonfiguruje się „white listy” i doda do nich IP które się potrzebuje, stworzy się użyteczne narzędzie…