Monitoring bezpieczeństwa Linux: integracja auditd + OSSEC cz. I

Artykuł poświęcony jest integracji dwóch znanych i sprawdzonych narzędzi opensource do monitoringu bezpieczeństwa: oprogramowania do audytu zmian w systemie Linux (auditd) i Host IDS OSSEC. Celem artykułu jest poznanie ograniczeń i wykorzystanie zalet obu tych narzędzi tak, by działając w tandemie umożliwiły detekcję podejrzanych zachowań na poziomie wywołań systemowych (syscalls).

Stosując porównania do taktyki wojskowej para auditd+OSSEC będzie u nas realizować zadania pary snajperskiej, gdzie obserwatorem będzie auditd, a zadanie ogniowe realizować będzie OSSEC za pomocą modułu Active Response. Zaczynamy zatem trening i polowanie na intruzów…

Po co monitorować wywołania systemowe?

Wywołania systemowe (syscalls) to żądania kierowane do jądra systemu operacyjnego, które powodują wykonanie uprzywilejowanych procedur. Podstawowe syscall’e to:

• open() – odczyt danych
• write() – zapis danych
• open()- otwarcie pliku
• fork() – utworzenie nowego procesu
• exec() – uruchomienienie programu

i wiele innych

Jak widzimy monitorowanie wywołań systemowych związnych z uruchamieniam nowych programów, odczytu i/lub zapisu plików może dostarczyć obrońcom informacji o działaniach intruzów w zaatakowanych systemach  np. za pomocą luki 0-day. Mimo tego, że doszło do włamania to, my jako obrońcy wcale nie jesteśmy jeszcze na straconej pozycji pod warunkiem , że zaimplementowaliśmy odpowiedni system monitoringu oraz procedury, które pozwolą nam na wykrycie i powstrzymanie trwającego ataku. Atakujący po udanym włamaniu będzie najczęście starał się zwiększyć swoje uprawnienia, rozpoznawał zaatakowany system od środka, wykradał dane, uruchamiał złośliwe oprogramowanie. Takie czynności w większości przypadków zostawiają ślady, istotą działań zespołów bezpieczeństwa jest wyłuskiwanie tych śladów i podjęcie tropu.

Do monitoringu powyższych czynności zaproponuję auditd, czyli oprogramowanie które na poziomie jądra Linuxa jest w stanie prowadzić audyt systemu z uwzględniem wywołań systemowych.

Obserwator: auditd

Instalację auditd można przeprowadzić za pomocą menadżera pakietów np.

Debian,Ubuntu

# apt-get install auditd audispd-plugins

Fedora, CentOS, RHEL (zwykle auditd powinien być zainstlowany)

#yum install audit

Pakiet auditd zawiera szereg binarek, które służą do zarządzania demonem auditd i wyszukiwania oraz analizy zarejestrowanych zdarzeń:

• auditctl: narzędzie do bieżącej konfiguracji demona auditd, sprawdzania statusu i uruchomionych reguł
• audispd: daemon to multiplikowania rejestrowanych zdarzeń do innych programów agregujących logi
• aureport: narzędzie do szybkich raportów generowanych na podstawie logu (auditd.log)
• ausearch: narzędzie do wyszukiwania zdarzeń z logu (auditd.log)
• autrace: narzędzie do analizy interakcji programów z jądrem
• aulast: narzędzie o funkcjonalności polecenia last ale wykorzystujące log auditd.log
• aulastlog: narzędzie o funkcjonalności polecenia lastlog ale wykorzystujące log auditd.log
• ausyscall: mapowanie ID wywołania systemowego na nazwę
• auvirt: informacje audytujące dotyczące wirtualnych maszyn

uruchomienie audytu przy każdym starcie systemu (Fedora, CentOS, RHEL)

#chkconfig auditd on

Wprowadzamy obserwatora do gry:

#service auditd start

i sprawdzamy stan usługi

#auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=10134 rate_limit=0 backlog_limit=320 lost=23 backlog=0

Na początku auditd nie zawiera żadnych reguł, co możemy sprawdzić każdorazowo poprzez użycie przełącznika –l

#auditctl -l
No rules

Czas postawić zadania naszemu obserwatorowi, czyli piszemy reguły. Reguły możemy dopisywać do pliku audit.rules (najcześciej w lokalizacji /etc/audit) lub za pomocą narzędzia auditctl z przełącznikiem -k.

Poniżej umieściłem kilka reguł, które pozwolą m.in. monitorować wszystkie polecenia wykonywane w systemie operacyjnym, zastawić pułapkę na intruzów, którzy chcieliby nie tylko zmodyfikować pliki systemowe ale „tylko” je odczytać, możemy być również bardziej granularni i włączać/wyłączać reguły monitorujące dla użytkowników o określonym UID, programów, plików, katalogów, ID wywołań systemowych.

Przykłady ciekawych, szczegółowych reguł do auditd można znaleźć w serwisie github:

• reguły użytkownika alienone
• reguły auditd w celu zachowania zgodności z wymogami PCI-DSS (Payment Card Industry Data Security Standard)
• reguły auditd w celu zachowania zgodności z wymogami NISPOM-DSS (National Industrial Security Program Operating Manual Data Security Standard)
• reguły auditd w celu zachowania zgodności z wymogami LSPP-DSS (Labeled Security Protection Profile Data Security Standard)
• reguły auditd w celu zachowania zgodności z wymogami NIST i DISA STIG dla RedHat’a

W tym artykule skupimy się na pełnym przeglądzie sytuacji, ponieważ nie chcemy, żeby jakiekolwiek podejrzane zachowanie nam umknęło, dlatego wykorzystamy pierwsze dwie reguły do śledzenia tego, co się dzieje w monitorowanym systemie.

auditctl -l
LIST_RULES: exit,always arch=1073741827 (0x40000003) key=execve syscall=execve
LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=execve syscall=execve
LIST_RULES: exit,always watch=/etc/passwd perm=rwa key=watch_passwd
LIST_RULES: exit,always watch=/etc/shadow perm=rwa key=watch_shadow

W ten sposób skonfigurowaliśmy wszechstronnego obserwatora, który będzie śledził całą aktywność w systemie i dodatkowo będzie skoncentrowany na jakimkolwiek dostępie do krytycznych plików (tu sztandarowy duet – passwd i shadow). Wygląda na to, że auditd jest narzędziem idealnym i nic mu nie umknie, i chociaż w większości przypadków jest to prawdą to jednak musimy być świadomi jego ograniczeń. Przykładowo, uruchomienie tego narzędzia w systemie wcześniej zainfekowanym dobrze przygotowanym rootkitem działającym na poziomie jądra systemu może spowodować, że złośliwa działalność zostanie ukryta w całości lub częściowo. Przykład ataku na oprogramowanie przechwytujące wywołania systemowe można znaleźć w artykule Exploiting Concurrency Vulnerabilities in System Call Wrappers. Na początku auditd może również przytłoczyć ogromem informacji, które rejestruje w swoim logu, a przeciążenie informacją może być czasem gorsze od jej braku. Wszystko jest kwestią ujarzmienia auditd i jego poprawnego wykorzystania.

Zanim jednak przejdziemy do integracji z HIDS OSSEC kilka przykładów wykorzystania auditd solo, które pozwolą zmniejszyć odrazę na widok wielolinijkowych logów auditd dla pojedynczego zdarzenia.

Auditd przykład 1: przeszukiwanie auditd.log

Analizowane zdarzenie to włamanie do serwera z wykorzystaniem konta nieuprzywilejowanego użytkownika. Intruz próbował skopiować plik shadow, zatem musiał zostać zauważony przez auditd:

$ cp /etc/shadow /tmp/shadow

w logu znajduje się poniższy wpis dotyczący tego zdarzenia, któremu auditd nadał numer 182858.

----
time->Wed Jul  8 23:41:06 2015
type=UNKNOWN[1327] msg=audit(1436391666.853:182858): proctitle=6370002F6574632F736861646F77002F746D702F736861646F77
type=PATH msg=audit(1436391666.853:182858): item=0 name="/etc/shadow" inode=3017833 dev=08:01 mode=0100640 ouid=0 ogid=42 rdev=00:00 nametype=NORMAL
type=CWD msg=audit(1436391666.853:182858):  cwd="/home/bartek"
type=SYSCALL msg=audit(1436391666.853:182858): arch=c000003e syscall=2 success=no exit=-13 a0=7fff9d4e293a a1=0 a2=0 a3=0 items=1 ppid=26215 pid=26768 auid=1005 uid=1005 gid=1003 euid=1005 suid=1005 fsuid=1005 egid=1003 sgid=1003 fsgid=1003 tty=pts4 ses=284 comm="cp" exe="/bin/cp" key="watch_shadow"

Linia PATH opisuje deskryptor pliku, którego dotyczy zdarzenie.

Linia CWD (current working directory) informuje, z jakiej lokalizacji zostało wydane polecenie.

Linia SYSCALL opisuje szczegóły wywołania systemowego:

•  nr wywołania systemowego (syscall=2 – open())
• wynik operacji zakończonej w tym wypadku niepowodzeniem ( success=noexit=-13)
• numer procesu i numer procesu rodzica (ppid=26215 pid=26768)
• numer terminala (tty=pts4)
• polecenie systemowe i lokalizacja binarki (comm=”cp” exe=”/bin/cp”)
• informacje o użytkowniku (auid=1005 uid=1005 gid=1003 euid=1005 suid=1005 fsuid=1005 egid=1003 sgid=1003 fsgid=1003)

Wykonanie tego samego polecenia ale z podniesionymi uprawnieniami za pomocą funkcjonalności sudo

#sudo cp /etc/shadow /tmp/shadow

daje następujący wynik w logu audt.log:

type=UNKNOWN[1327] msg=audit(1436396977.941:190894): proctitle=7375646F006370002F6574632F736861646F77002F746D702F736861646F77
type=PATH msg=audit(1436396977.941:190894): item=0 name="/etc/shadow" inode=3018009 dev=08:01 mode=0100640 ouid=0 ogid=42 rdev=00:00 nametype=NORMAL
type=CWD msg=audit(1436396977.941:190894):  cwd="/home/bartek"
type=SYSCALL msg=audit(1436396977.941:190894): arch=c000003e syscall=2 success=yes exit=6 a0=7faea7815bdc a1=80000 a2=1b6 a3=0 items=1 ppid=474 pid=2566 auid=1005 uid=1005 gid=1003 euid=0 suid=0 fsuid=0 egid=1003 sgid=1003 fsgid=1003 tty=pts4 ses=298 comm="sudo" exe="/usr/bin/sudo" key="watch_shadow"

Warto zwrócić uwagę, że tym razem odczyt pliku został zakończony powodzeniem  (success=yes), a operacja została przeprowadzona z podniesionymi uprawnieniami na co wskazuje pole euid (effective uid), które teraz ma wartość 0, czyli UID użytkownika root. W polu comm zawarta jest informacja o programie sudo, nie mamy natomiast informacji o argumentach tego polecenia. W tym celu skorzystamy z tego, że auditd monitoruje wszystkie uruchomione polecenia wraz z argumentami za pomocą reguły nazwanej execve i wyszukamy wszystkie zdarzenie związane z poleceniem sudo i regułą monitorującą execve.

ausearch -x sudo -k execve

czego wynikiem jest takie zdarzenie:

type=UNKNOWN[1327] msg=audit(1436396973.213:190881): proctitle=7375646F006370002F6574632F736861646F77002F746D702F736861646F77
type=PATH msg=audit(1436396973.213:190881): item=1 name=(null) inode=13895173 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=PATH msg=audit(1436396973.213:190881): item=0 name="/usr/bin/sudo" inode=14027293 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=CWD msg=audit(1436396973.213:190881):  cwd="/home/bartek"
type=EXECVE msg=audit(1436396973.213:190881): argc=4 a0="sudo" a1="cp" a2="/etc/shadow" a3="/tmp/shadow"
type=BPRM_FCAPS msg=audit(1436396973.213:190881): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=0000003fffffffff new_pi=0000000000000000 new_pe=0000003fffffffff
type=SYSCALL msg=audit(1436396973.213:190881): arch=c000003e syscall=59 success=yes exit=0 a0=ebb928 a1=b98588 a2=cf3008 a3=8 items=2 ppid=474 pid=2566 auid=1005 uid=1005 gid=1003 euid=0 suid=0 fsuid=0 egid=1003 sgid=1003 fsgid=1003 tty=pts4 ses=298 comm="sudo" exe="/usr/bin/sudo" key="execve"

gdzie szczególnie interesująca jest linia EXECVE zawierająca wszystkie argumenty polecenia. Widzimy zatem, że poprzez odpowiednie sformatowanie linii EXECVE z logu audit.log możemy otrzymywać bieżące informacje o tym, jakie polecenia i programy są uruchamiane w monitorowanym systemie (Przykład nr 5).

Auditd przykład 2: analiza źródła malware’u

Po wykryciu podejrzanej aktywności na hoście, auditd jest w stanie ułatwić nam zadanie ustalenia źródła złośliwego oprogramowania. Do tego celu wykorzystujemy pole ppid (parent process id) i sprawdzamy, w jaki sposób zostało uruchomione polecenie kopiowania plików.

#ausearch -p 474
type=UNKNOWN[1327] msg=audit(1436352887.672:155389): proctitle=7368002D63006E657473746174202D74616E207C67726570204C495354454E207C67726570202D76203132372E302E302E31207C20736F7274
type=PATH msg=audit(1436352887.672:155389): item=1 name=(null) inode=13895173 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=PATH msg=audit(1436352887.672:155389): item=0 name="/bin/sh" inode=4194326 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=CWD msg=audit(1436352887.672:155389):  cwd="/"
type=EXECVE msg=audit(1436352887.672:155389): argc=3 a0="sh" a1="-c" a2=6E657473746174202D74616E207C67726570204C495354454E207C67726570202D76203132372E302E302E31207C20736F7274
type=SYSCALL msg=audit(1436352887.672:155389): arch=c000003e syscall=59 success=yes exit=0 a0=7fb99ca62c23 a1=7fff2d71ea20 a2=7fff2d7243d8 a3=7fb99d0a29d0 items=2 ppid=2748 pid=474 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sh" exe="/bin/dash" key="execve"

Linia SYSCALL zawiera informację, że procesem nadrzędnym jest powłoka systemowa dash, w innym wypadku mógłby to być skrypt lub binarka, jednak w każdym z tych przypadków możemy podążać po nitce do kłębka ustalając, gdzie jest źródło podejrzanych zachowań, aby ostatecznie zweryfikować, czy jest to malware, włamanie czy też autoryzowane działanie adminstratorów. Niejednokrotnie trzeba sprawdzić kilka takich potomnych procesów, by na końcu dotrzeć do zarażonej biblioteki.

Jeśli analizując kolejne procesy krok po kroku dojdziemy do sytuacji, że ich źródłem jest np.któraś binarka systemowa chociażby polecenie less, pakiet auditd zawiera narzędzie autrace, które ma funkcjonalność zbliżoną do strace. Za pomocą autrace możemy przeprowadzić analizę odwołań do plików i bibliotek, z których korzysta dana binarka, co również przybliżyć nas może do źródła malware’u.

# autrace /usr/bin/less
Waiting to execute: /usr/bin/less
Missing filename ("less --help" for help)
Cleaning up...
Error deleting rule (No such process)
Trace complete. You can locate the records with 'ausearch -i -p 8312'

Dostajemy podpowiedź, żeby użyć polecenia ausearch -i -p 8312, w tym przykładzie z poszukiwaniem malware’u proponuje trochę użyć:

# ausearch -r -p 8312 |aureport --file --summary

File Summary Report
===========================
total  file
===========================
3  /etc/ld.so.nohwcap
2  /lib/terminfo/x/xterm
1  /usr/bin/.sysless
1  /etc/sysless
1  /root/.less
...
1  /usr/share/terminfo
1  /root/.terminfo
1  /lib/x86_64-linux-gnu/libc.so.6
1  /lib/x86_64-linux-gnu/libtinfo.so.5

Uwaga: polecenie autrace poprzedzamy wyczyszczeniem reguł za pomocą auditctl -D.

Auditd przykład 3: zaawansowane wyszukiwanie (ausearch) i tworzenie raportów (aureport)

Poniżej kilka przydatnych przełączników do przeszukiwania logu audit.log

ausearch -ts today -x rm

wyszukuje zdarzenie z bieżącego dnia  związane z usuwaniem plików za pomocą polecenia rm, inne ciekawe przedziały czasu, które możemy określić za pomocą przełącznika –ts to now,  recent (ostatnie 10 minut),  today,  yesterday, this-week, this-month, this-year.

ausearch -ts recent -ui 1001

wyszukuje aktywność użytkownika o UID 1001

ausearch -i

przełącznik -i zamienia wartości numeryczne na nazwy np. UID’y na nazwy użytkowników

ausearch -k watch_passwd

przełącznik -k umożliwia wyszukiwanie, czy zostały zarejestrowane zdarzenia, dla których przygotowaliśmy reguły w pliku audit.rules.

W podręczniku do ausearch znajdziemy kolejne przykłady przełączników, które możemy wykorzystać do odpytwania auditd o to, co zaobserwował.

Oprócz precyzyjnych odpowiedzi w postaci wyłuskiwania informacji z logu za pomocą ausearch, pakiet auditd zawiera również binarkę aureport, która służy do tworzenia raportów i podsumowujących audyt systemu w szerszym kontakście czasowym.

Za pomocą aureport możemy wygenerować raport o wszystkich kolejnych uruchomieniach programów wykonywalnych w godzinach 12.00-13.00

# aureport -ts 12:00:00 -te 13:00:00 -i -x

Executable Report
====================================
# date time exe term host auid event
====================================
...
4783. 09.07.2015 12:59:59 /bin/grep (none) ? unset 246363
4784. 09.07.2015 12:59:59 /bin/netstat (none) ? unset 246364
4785. 09.07.2015 12:59:59 /usr/bin/sort (none) ? unset 246365
4786. 09.07.2015 12:59:59 /bin/grep (none) ? unset 246366
4787. 09.07.2015 12:59:59 /bin/dash (none) ? unset 246362

Tu raport o wszystkich programach wykonanych w bieżącym dniu z podsumowaniem liczby wywołań tych programów.

# aureport -ts today -i -x --summary

Executable Summary Report
=================================
total  file
=================================
36053  /bin/dash
33650  /usr/bin/sort
26699  /bin/grep
13339  /bin/netstat
1617  /usr/bin/dpkg
1346  /usr/lib/policykit-1/polkitd
1033  /bin/ps
451  /usr/sbin/cron
367  /usr/bin/last
367  /bin/df
317  /var/ossec/bin/ossec-syscheckd
...

Raport o nieudanych logowaniach za pomocą przełącznika -au

#aureport -au

Authentication Report
============================================
# date time acct host term exe success event
============================================

Podsumowanie o modyfikacjach kont uzyskamy za pomocą przełącznika -m

aureport -m

Account Modifications Report
=================================================
# date time auid addr term exe acct success event
=================================================

Przydatną opcją jest też wygenerowanie raportu o anomaliach za pomocą przełącznika -n.

Co ciekawe oba polecenia ausearch i aureport możemy łączyć potokowo:

# ausearch -ts yesterday -f /etc/shadow |aureport -x --summary

Executable Summary Report
=================================
total  file
=================================
171  /var/ossec/bin/ossec-syscheckd
113  /usr/sbin/cron
45  /usr/lib/gnome-screensaver/gnome-screensaver-dialog
19  /bin/su
6  /usr/sbin/usermod
6  /bin/cp
6  /bin/ls
5  /usr/bin/passwd
4  /usr/bin/sudo
2  /usr/bin/cmp
1  /usr/lib/accountsservice/accounts-daemon

Za pomocą powyższego polecenia wykonaliśmy podsumowanie wszystkich programów, które danego dnia uzyskiwały dostęp do pliku /etc/shadow, od razu rzuca się w oczy niepokojące polecenie kopiowania (/bin/cp) tego pliku wykonane 6 razy.

Auditd przykład 4: centralne logowanie

Dobrą praktyką monitorowania jest wykorzystanie centralnego logowania i choć wydaje się to oczywiste to, realia pozostawiają wiele do życzenia. Auditd zawiera plugin audispd, który sprawia, że konfiguracja przesyłania logu audit.log do systemu zdalnie logującego jest całkiem prosta. W tym przykładzie rozpoczniemy od konfiguracji serwera rsyslog:

plik /etc/rsyslog.conf na serwerze:

# provides TCP syslog reception
$ModLoad        imtcp
$InputTCPServerRun      2514
$AllowedSender  TCP,127.0.0.1,192.168.56.102
$template       HostAudit,"/var/log/rsyslog/%HOSTNAME%/audit.log"
$template       auditFormat,"%msg%\n"
local6.*        ?HostAudit;auditFormat

Serwer syslog będzie nasłuchiwał na porcie 2514 TCP, a log audit.log zostanie umieszczony w lokalizacji /var/log/rsyslog/%HOSTNAME% z zachowaniem formatu auditd, co oznacza, że można korzystać z narzędzi takich jak ausearch czy aureport podając lokalizację pliku za pomocą przełącznika -if, np.

# ausearch -f /etc/passwd -if /var/log/rsyslog/ubuntu/audit.log

plik /etc/rsyslog.conf u klienta:

$ModLoad imfile   # provides kernel logging support
# umieścić na dole pliku
$InputFileName  /var/log/audit/audit.log
$InputFileTag   tag_audit_log:
$InputFileStateFile     audit_log
$InputFileSeverity      info
$InputFileFacility      local6
$InputRunFileMonitor
local6.*        @@192.168.56.1:2514

Przy konfiguracji syslog trzeba szczególnie uważać w plikach konfiguracyjnych na rozdzielenie selektorów i działań za pomocą tabulacji a nie spacji.

w konfiguracji pluginu audispd u klienta w pliku /etc/audisp/plugins.d/syslog.conf włączamy opcję przesyłania zdarzeń również do sysloga:

active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_INFO
format = string

Komunikację klient-serwer zawierającą tak wrażliwe dane jak log audytu systemu musimy obowiązkowo zaszyfrować, a na oficjalnej stronie rsyslog.com można znaleźć tutorial konfiguracji TLS dla rsyslog.

Auditd przykład 5: podgląd wszystkich poleceń w czasie rzeczywistym (skrypt w Pythonie formatujący audit.log)

Pomimo, że pierwsze przykłady powinny sprawić, że log audit.log nie przyprawia już o ból głowy, a narzędzia takie jak ausearch i aureport usprawniają wyszukiwanie i analizę to, jednak warto mieć własne narzędzia, które pozwolą wyciągać z logu esencję, czyli w naszym przypadku – wszystkie polecenia uruchamiające programy wykonywalne w czasie rzeczywistym. Do tego celu można zastosować krótki skrypt w Pythonie, który sformatuje log audit.log pod nasze potrzeby.

tailAuditLog.py

from sh import tail
import re
def callback(m):
	try:
		m = m.group(0)
		m=m[1:]
		return '='+m.decode('hex')
	except :
		return '='+m
# runs forever
for line in tail("-f", "/var/log/audit/audit.log", _iter=True):
	if "type=EXECVE" not in line:
		continue
	_,msg = line.strip().split('msg=')
	aid,exe = msg.split(": ",1)
	time,id = aid.split(":",1)
	id = re.sub(r'\)', '',id)
	exe = exe.split(" ",1)[1]
	exe = re.sub(r'=[0-9A-F]{5,}',callback,exe)
	exe = re.sub(r'a[0-9]=', '',exe)
	exe = re.sub(r'"', '',exe)
	print(id+" "+exe)

Działanie logowania wszystkich komend na poziomie wywołań systemowych najlepiej sprawdzić otwierając równolegle dwa okna terminala:

1. W pierwszym uruchamiamy skrypt poleceniem: python /root/tailAuditLog.py
2. W drugim oknie wydajemy dowolne komendy powłoki, uruchamiamy programy, etc.

Skrypt tailAuditLog.py do monitoringu uruchamianych poleceń w systemie

Wynikiem działania skryptu są kolejne zarejestrowane wywołania systemowe EXECVE, gdzie w pierwszej kolumnie umieszczony został ID zdarzenia, co można wykorzystać do szczegółowego analizy narzędziami pakietu auditd.

Jeśli skonfigurowaliśmy centralne logowanie opisane w przykładzie numer 4 to, skrypt najlepiej uruchomić na serwerze zmieniając w skrypcie lokalizację pliku auditd.log.

Podsumowanie

W pierwszej części artykułu poznaliśmy pierwszego gracza -auditd, którego zadaniem jest obserwacja wywołań systemowych, jakie mają miejsce w monitorowanym systemie. Warto poznać to narzędzie do audytu z uwagi na szeroki wachlarz możliwości logowania zdarzeń związanych zarówno z wywołaniami systemowymi jak z deskryptorami plików. Co więcej, elastyczność budowania reguł pozwala wypełniać wymagania jakie stawiane są przez wiele standardów regulujących szczegółowość audytu (NIST, PCI_DSS, itp.) Mam nadzieję, że przykłady użycia narzędzi ausearch i aureport pozwoliły oswoić się z dużą ilością informacji jaką dostarcza auditd.Auditd widzi dużo i dużo rejestruje, nie zawiera jednak modułu alertującego, ani blokującego niechcianą aktywność.

W drugiej części artykułu przedstawię niezbędną konfigurację OSSEC HIDS do współpracy z auditd, czyli temat będzie dotyczył pisania własnych dekoderów, pisania reguł OSSEC i użycia modułu Active Response, dzięki któremu OSSEC nie jest tylko systemem do wykrywania włamań, ale też do precyzyjnego blokowania intruzów. Poprzez użycie wymienionych narzędzi zwiększamy swój arsenał, co sprawia, że nie jesteśmy bezbronni. Co więcej, pora również przestawić myślenie z wydawałoby się oczywistego „czekania na incydent” na strategię wyjścia do przeciwnika. Zmiana strategii polega na nastawieniu ofensywnym będąc w obronie. Myśląc tak, jak włamywacz, możemy przewidywać jego ruchy i tam zastawiać własne zasadzki. Auditd jest na pewno narzędziem, za pomocą którego możemy to realizować, bo zwiększa radykalnie nasz obraz sytuacji.

 –Bartek Jerzman