<--  | Strona G��wna  | Mapa Serwisu  | Indeks  | Szukaj

Mulyadi Santosa <a_mulyadi/at/softhome.net> O Autorze: Nazywam si� Mulyadi Santosa. Mieszkam w Indonezji i pracuj� jako niezale�ny autor i konsultant. Moje zainteresowania to klastry, systemy bezpiecze�stwa i sieci. Uruchomi�em te� ma�� prywatn� firm� zajmuj�c� si� dziedzin� klastr�w. Moj� uwag� przyci�gaj� szczeg�lnie OpenMosix and openSSI. W wolnym czasie ulubionymi rozrywkami s� czytanie i uprawianie sportu. Mo�esz wys�a� mi e-mail na a_mulyadi@softhome i podyskutowa� o tym. Translated to Polish by: Daniel Maciejewski <danielma/at/go2.pl> Zawarto��: Wprowadzenie Syscalltracker Zainteresowany ??? Kompilacja Syscalltracker'a Regu�y Dyskusja dotycz�ca tego artyku�u

�ledzenie Linuxa za pomoc� Syscalltracker'a Notka: Czasami chcemy przyjrze� si� naszemu Linuxowi bardziej z bliska. Jest w nim wiele program�w s�u��cych do tworzenia log�w, narz�dzi do wykrywania intruz�w czy program�w testuj�cych integralno��. Chcia�bym teraz przedstawi� mechanizm s�u��cy do obserwowania Linuxa na poziomie kernela, kt�ry oferuje wi�ksz� niezawodno�� oraz szerszy wachlarz zastosowa�. _________________ _________________ _________________

Wprowadzenie

Pewnego dnia czekalem na list� mailow� omawiaj�c� zagadnienie "clustering middleware tool". Przypadkowo znalaz�em tam watek dotycz�cy anomalii spowodowanych przez �atk� kernela. I wtedy osoba odpowiadaj�ca na tego maila stwierdzi�a, �e spr�buje zrekonstruowa� powsta�y problem na podstawie krok�w opisanych przez osob� pierwsz�. Ta osoba u�ywa�a narz�dzia zwanego Syscalltracker, w celu rozgryzienia zaistnia�ego problemu. Zastanowi�o mnie "Co to za narz�dzie ten Syscalltracker? Jakie s� jego mo�liwo�ci?". Dla zwyk�ego u�ytkownika jak ja nazwa "Syscalltracker" wygl�da�a tajemniczo i podejrzanie :)

Syscalltracker

Istnieje rozwi�zanie �ledz�ce tego rodzaju problemy. Nie jest mo�e 100%'owo doskona�e, ale wystarczaj�co dobre w wiekszo�ci przypadk�w. Bazuje ono na fakcie, �e ka�da akcja lub komenda wykonana z shella, program u�ytkownika czy demon (innymi s�owy - KA�DY proces) musi by� uruchomiony jednym b�d� wiecej wywo�aniami procedur systemowych, powszechnie nazywanych wywo�aniami systemowymi. Pr�bujesz skasowa� plik? To znaczy, �e wywo�ujesz unlink. Uruchomi�e� skrypt shella? Wtedy musi by� wywo�ane exec() lub execve(). Tak wi�c praktycznie ka�da akcja odniesiona do systemu jest bezpo�rednio interpretowana jako wywo�anie systemowe. W�a�nie dzi�ki temu �ledzenie bazuj�ce na wywo�aniach systemowych mo�e by� mocn� broni�.

Zainteresowany ???

# tar xzvf syscalltrack-0.82.tar.gz

Teraz sprawd� czy masz kod �r�d�owy j�dra w /usr/src:

# rpm -qa | grep -i kernel-source

LUB

# ls -al /usr/src/linux-2.4

Je�eli powy�sze komendy poka��, �e nie masz zainstalowanych �r�de�, musisz je doinstalowa�. �r�d�a znajdziesz na p�ytce Redhat CD (#2):

# rpm -replacepkgs -Uvh /path/to/your/RPM/kernel-source-2.4.18-3.i386.rpm

Zwr�� uwag�, �e MUSISZ skompilowa� Syscaltracker'a bazuj�cego na tej samej wersji j�dra (i innych dodatkowych �atkach), kt�ra jest aktualnie uruchomiona na twoim Linux'ie. Przyk�ad: je�li u�ywasz standardowego j�dra z Redhat 7.3, wtedy musisz skompilowa� �r�d�a kernela z p�ytki Redhat CD. Albo je�li chcesz u�ywa� innego, wybranego przez ciebie j�dra, musisz samodzielnie skompilowa� Syscalltracker'a bazuj�cego na �r�d�ach tego j�dra.

Opr�cz kodu �r�d�owego, dla u�atwienia kompilacji Syscalltrackera, potrzebujesz tak�e Redhat'owego pliku konfiguracyjnego j�dra. Spr�buj sprawdzi� zawarto�� katalogu /boot:

# ls -al config*

Je�eli uzyska�e� wynik w stylu 'config-2.4.18-3', skopiuj ten plik to katalogu /usr/src/linux-2.4. Zmie� jego nazw� na '.config'

# cp /boot/config-2.4.18-3 /usr/src /linux-2.4/.config

Je�li tego pliku z jakiego� powodu nie ma, mo�esz skopiowa� go z katalogu ze �r�d�ami j�dra. Znajduje si� on w podkatalogu configs. Musisz wybra� ten, kt�ry odpowiada twojej aktualnie uruchomionej wersji kernela. A wi�c najpierw sprawd� jaka to wersja:

# uname -a

Wykonanie powy�szej komendy powinno w rezultacie wy�wietli� wersj� kernela. Mo�esz to zgadn��. Za��my, �e uzyskany wynik to "kernel-2.4.18-3-i386" - wtedy potrzebujesz skopiowa� plik kernel-2.4.18-3-i386.config

# cd /usr/src/linux-2.4
# cp configs/kernel-2.4.18-3-i386.config ./.config

Teraz musisz wykonaďż˝:

#cd /usr/src/linux-2.4.18-3
# make mrproper
# make menuconfig

Zaaplikuj potrzebne ci ustawienia a nast�pnie zapisz/wyjd�. Je�li u�ywasz samodzielnie skompilowanego j�dra, a zgubi�e� stary plik konfiguracyjny j�dra, musisz starannie go odtworzy�, aby unikn�� p�niej problem�w (Mam nadziej�, �e nie :-))

Kompilacja Syscalltracker'a

Do teraz przygotowali�my wszystkie potrzebne rzeczy. Mo�emy rozpocz�� kompilacj� Syscalltracker'a:

# cd /usr/src/syscalltrack-0.82
# ./configure (or ./configure -with-linux=/path/to/your/linux/kernel/source)
# make && make install

Je�eli kompilacja przebieg�a pomy�lnie, odnajdziesz dwa nowe modu�y:

1. /lib/modules/2.4.18-3/syscalltrack-0.82/sct_rules.o
   
   
2. /lib/modules/2.4.18-3/syscalltrack-0.82/sct_hijack.o
   
   

S� to modu�y odpowiedzialne za �ledzenie twojego systemu. Sam autor u�ywa terminu "system call hijacking", oznaczaj�cego przechwytywanie wywo�a� systemowych i wykonywanie pewnych zdefiniowanych wcze�niej akcji przed wykonaniem w�a�ciwej procedury. Modu�y te trzeba za�adowa�. Do �adowania modu��w u�ywamy specjalnego wbudowanego skryptu:

# sct_load (jako root)

Upewnij si�, �e kernel za�adowa� modu�y, u�ywaj�c lsmod. Powiniene� zobaczy� co� w stylu:

Module     Size  Used by    Not tainted
sct_rules  257788   2
sct_hijack 110176   1      [sct_rules]
<…..cut………..>

Regu�y

Gratulacje !!! Za�adowa�e� modu�y i masz uruchomionego Syscalltracker'a. Ale to nie koniec. Potrzebujesz jeszcze napisa� regu�y wymagane przez Syscalltracker'a do w�a�ciwej pracy. Zacznijmy od prostej regu�y:

rule
 {
   syscall_name=unlink
   rule_name=unlink_rule1
   action
   {
     type=LOG
     log_format {%comm : %params delete by %euid --> %suid}
   }
   when=before
}

Ka�d� regu�� zdefiniowan� dla Syscalltrackera rozpoczyna zastrze�one s�owo "rule" poprzedzone przez "{". Nast�pnie musisz zadeklarowa�, kt�re wywo�anie systemowe chcesz obserwowa�, u�ywaj�c parametru "syscall_name". Jest wiele wywo�a� systemowych, z kt�rych mo�esz wybra�. Aby zobaczy� ich kompletn� list� spr�buj zajrze� do pliku '/usr/local/lib/syscalltrack-0.82/syscalls.dat-2.4.18-3'. Znaczenie niekt�rych wywo�a� systemowych jest ci�ko odgadn��, ale s� te� wywo�ania bardzo �atwe. Teraz wybior� unlink(). To wywo�anie systemowe jest uruchamiane za ka�dym razem, gdy kto� lub co� pr�buje skasowa� plik. My�l�, �e to dobry wyb�r na pocz�tek, wi�c nasz� ide� jest obserwowa� kasowania wyst�puj�ce w naszym systemie.

W parametrze "rule_name", musisz dostarczy� nazw� regu�y. Jest ona dowolnym wpisem, po prostu napisz dowoln� �atw� do zrozumienia nazw�. Ja wybra�em "unlink_rule1". W sekcji "action" musisz wpisa� co Syscalltracker ma zrobi� ka�dorazowo gdy wyst�pi odpowiednie wywo�anie systemowe. Syscalltracker wspiera r�ne akcje, ale tutaj u�yjemy akcji typu LOG. Ta akcja wypisze logi na urz�dzenie /dev/log. Zgodnie z tym co pisze na stronie internetowej na li�cie TODO (do zrobienia), s� plany aby zrobi� przepisywanie wywo�a� systemowych. Znaczy to, �e m�g�by� manipulowa� parametrami wywo�ania systemowego i wstawia� sw�je w�asne parametry :-)

Dla akcji LOG musisz zdefiniowa� format wyj�ciowy. Dost�pne s� pewne makra, pozwalaj�ce uzyska� szczeg�owe informacje:

%ruleid -> nazwa regu�y, do kt�rej pasuje przechwycone wywo�anie systemowe
%sid    -> numer identyfikacyjny wywo�ania systemowego
%sname  -> nazwa wywo�ania systemowego
%params -> parametry wywo�ania systemowego
%pid    -> ID procesu, kt�ry wykonuje wywo�anie systemowe
%uid    -> ID u�ytkownika, kt�ry u�ywa wywo�ania systemowego
%euid   -> efektywny ID u�ytkownika, kt�ry u�ywa wywo�ania systemowego
%suid   -> numer SUID u�ytkownika kt�ry u�y� wywo�ania systemowego
%gid    -> ID grupy u�ytkownika, kt�ry u�ywa wywo�ania systemowego
%egid   -> efektywny ID grupy u�ytkownika, kt�ry u�ywa wywo�ania systemowego
%sgid   -> numer SGID grupy u�ytkownika, kt�ry u�y� wywo�ania systemowego
%comm   -> nazwa komendy, kt�ra wykonuje wywo�anie systemowe
%retval -> warto�� zwr�cona przez wywo�anie systemowe. Dzia�a tylko
           dla akcji LOG z typem "after"

Za��my, �e wpisa�em

.log_format {%comm : %params delete by %euid --> %suid}

Oznacza to "Chc� uzyska� log na temat ka�dej komendy, kt�ra uruchomi�a wywo�anie systemowe unlink, z efektywnym identyfikatorem u�ytkownika EID oraz identyfikatorem SUID."

W parametrze when, mo�emy wybra� pomi�dzy "before" i "after". R�nica jest oczywista - je�li u�ywamy "before" rejestrowanie zdarzenia nast�pi zanim zostanie wykonane wywo�anie systemowe. Je�li u�yjemy "after" rejestrowanie zdarzenia b�dzie mia�o miejsce po wykonaniu wywo�ania systemowego.

Na ko�cu regu�y dajemy "}". Ca�a regu�a mo�e by� zapisana wewn�trz zwyk�ego pliku tekstowego, na przyk�ad nazwijmy go "try.conf" i zapiszmy w "/tmp". Teraz musisz za�adowa� t� regu�� do Syscalltrackera

# sct_config upload /tmp/try.conf

Je�eli regu�a napisana jest poprawnie, otrzymasz komunikat "Successfully uploaded rules from file '/tmp/try.conf' ".

OK, wszystko posz�o dobrze. Teraz przysz�a faza testu. Uruchom konsol�, powiedzmy xterm z Xwindow. Na jednej konsoli ogl�daj komunikaty Syscalltrackera u�ywaj�c

# sctlog

Za chwil� zobaczysz wynik dzia�ania mechanizmu przechwytywania wywo�ania systemowego odpowiadaj�cego twojej regule. Na innej konsoli zr�b co� takiego:

# cd /tmp
# touch ./dummy
# rm ./dummy

U�ywaj�c powy�szej regu�y, otrzymasz prawdopodobnie nast�puj�cy wynik na konsoli z sctlog:

"rm" : "./dummy" delete by 0 --> 0

Na podstawie powy�szego komunikatu za chwil� dowiesz si� co si� dzieje.

Komenda "rm" z parametrem "./dummy" wykona�a wywo�anie systemowe unlink(). Lub innymi s�owy rm zosta�o u�yte do skasowania pliku. Ta komenda u�ywa efektywnego id u�ytkownika o numerze 0 (lub root)"

rule
{
   syscall_name = unlink
   rule_name = prevent_delete
   filter_expression {PARAMS[1]=="/etc/passwd" && UID == 0}
   action {
     type = FAIL
     error_code = -1
   }
   when = before
}

Jest ona podobna do te z pierwszego przyk�adu, z tym, �e teraz u�ywamy akcji FAIL. Wy��cznie dla FAIL musimy zdefiniowa� zwracan� warto�� dla przechwyconego wywo�ania systemowego. Ja u�ywam tu warto�ci "-1" czyli "operacja nie dozowlona". Kompletn� list� warto�ci znajdziesz w pliku /usr/include/asm/errno.h.

W linii zawieraj�cej "filter_expression" definuj� warunek dla kt�rego wykonywane jest sprawdzanie - je�li pierwszy parametr (wywo�ania systemowego) jest r�wny "/etc/passwd". Dlatego potrzebujemy zmiennej PARAMS. Uwaga: ka�da sekcja ma swoje w�asne wymagane parametry. To sprawdzanie nie jest idealne poniewa� kto� mo�e u�y� czego� w stylu "cd /etc && rm -f ./passwd". A to zadzia�a ju� prawid�owo !!! U�ywamy tak�e sprawdzenia czy UID jest r�wny 0 (root).

Dodaj t� regu�� do pliku z poprzedni� regu�� i prze�aduj:

# sct_config delete
# sct_config upload /tmp/try.conf

Zwr�� uwag�, �e kolejno�� regu� jest wa�na. Je�li zadeklarujesz regu�� "prevent_delete" przed "unlink_rule1" wtedy gdy zrobisz :

# rm -f /etc/passwd

najpierw zostanie dopasowana regu�a "prevent_delete" i ca�a akcja zako�czy si� niepowodzeniem. Regu�a "unlink_rule1" zostanie zignorowana. Ale je�li zamienisz kolejno�� regu� ("unlink_rule1" przed "prevent_delete"), wtedy dostaniesz komunikat (wynik pierwszej regu�y) bez zatrzymywania akcji !

Ineteresuj�ce jest te� inne wywo�anie systemowe zwane ptrace. Z "man ptrace", mo�esz dowiedzie� si�, �e to wywo�anie systemowe jest u�ywane w celu obserwacji i kontroli uruchomienia innego programu. W odpowiednich r�kach ptrace mo�e by� podr�cznym narz�dziem do debuggowania, ale w nieodpowiednich mo�e by� ono u�yte do analizowania dziur systemowych i u�ywania ich. Dodajmy regu�� do obserwowania ptrace'a.

Aby to zrobi� u�yj regu�y jak poni�ej:

rule
{
    syscall_name=ptrace
    rule_name=ptrace_rule1
    action {
        type=LOG
      log_format {%comm : %params issued ptrace by %euid --> %suid}
  }
    when=before
}

Zauwa�, �e deklarujemy ptrace jako wywo�anie systemowe, kt�re ma by� �ledzone. Dla testu, u�yj programu strace, �eby wypr�bowa� t� regu��. Najpierw za�aduj powy�sz� regu�� do syscalltracker'a i uruchom sctlog. Wtedy uruchom strace w stosunku np. do komendy ls:

# strace /bin/ls

W sctlog, mo�esz zobaczy� kilka linijek w stylu:

"strace" : 3, 2019, 24, -1073748200 issued ptrace   by 0 --> 0
"strace" : 24, 2019, 1, 0 issued ptrace   by 0 --> 0
"strace" : 3, 2019, 44, -1073748200 issued ptrace   by 0 --> 0
"strace" : 3, 2019, 24, -1073748200 issued ptrace   by 0 --> 0
"strace" : 3, 2019, 0, -1073748216 issued ptrace   by 0 --> 0
"strace" : 7, 2019, 1, 0 issued ptrace   by 0 --> 0

Dla tych, kt�rzy nie znali strace, jest to narz�dzie (bardzo silne) do �ledzenia wywo�a� systemowych wydawanych wewn�trz wykonywalnego pliku. Strace wewn�trznie u�ywa ptrace aby podczepi� si� do docelowego programu, dzi�ki czemu mo�e go �ledzi�. Obecnie strace oraz Syscalltracker stanowi� idealne combo do audytu systemu oraz plik�w, dlatego my�l�, �e warto po�wi�ci� im chwil�. Redhat 7.3/8/9 ju� go ma. Zainstaluj po prostu RPM (tutaj dla Redhat 7.3):

# rpm -Uvh /path/to/your/Redhat/RPM/strace-4.4-4.i386.rpm

Teraz jeste� jeden krok dalej w diagnozowaniu swojego systemu. Syscalltracker daje u�ytkownikowi elastyczno�� i mo�liwo�� nauczenia si� czego� o wywo�aniach systemowych. Dodatkowo je�li chcesz zobaczy� wszystkie regu�y, kt�re zosta�y za�adowane, wpisz:

# sct_config download

# sct_config delete

# sct_unload

Dyskusja dotycz�ca tego artyku�u

2004-01-12, generated by lfparser version 2.43