Download lf-2004_01-0320.pdf

Contents : LinuxFocus article number 320 http://linuxfocus.org Tracking Linux Internals with Syscalltracker by Mulyadi Santosa a mulyadi/at/softhome.net About the author: My name is Mulyadi Santosa. I live in Indonesia and work as freelance writer and consultant. My interest is clustering system security and networking. I also run small privately own company in clustering field aiming for selling cost-of-the-shelf clustering. OpenMosix and openSSI really drawn my focus. In my spare time reading and sport are great leisure. You can send me e-mail to a mulyadi@softhome and discuss about it Abstract: Sometimes we want to watch our Linux system more closely. The are many of logging prograns instrusion detection tools integrity checking tools and so on. This time I want to introduce you to a mechanism to watch Linux at kernel level which offer more reliability and more broader coverage. Introduction One day I hang on mailing list discussing about clustering middleware tool. Accidentally there was a thread discussing system anomaly caused by a kernel patch. And then a person replied that he try to recontruct the problem according to steps reported by first person. This person uses a tool called Syscalltracker to help him pinning the problem that arises. And (for myself) I wonder "What kind of tool is Syscaltracker What is its capability " For casual user like me the name "Syscalltracker" alone left me with mysterious suspect :-) Syscalltracker (http://syscalltrack.sourceforge.net) is a collection of kernel modules to help one tracing system calls issued internally by Linux kernel. What is it for Generally we can use it to trace the cause of some system misbehaviour that is hard to solve by ordinary tracing or debugging mechanism. Here is a simple example: suppose you have configuration file in /etc directory named inetd.conf (base configuration for INETd daemon). You had configured it to run several system daemon and disabled other. And then you start up inetd and everything went fine at first place. But suddenly /etc/inetd.conf dissapeared. Luckily you have the backup and you quickly restore it from fresh backup. And then you restart inetd base on newly configuration. This time something has add newlines to inetd.conf and inserted a command to start mysterious daemons. You got confused... "who did this " "Is it caused by a daemon started by inetd itself " "Is there any exploit trying to compromised my system ". Quickly you "cat" over the system log fire up "top" and "ps" to look for unusual process or user that exist but none of them is visible. There is a solution for tracing this kind of problem. Not a 100% perfect solution but sufficient enough for handling major cases. It is based on the fact that every action or command issued from a shell user program or daemon (in other word ANY process) must be executing one or more internal system procedure widely known as system calls. Are you trying to delete a file It means you call unlink. You ran a shell script Then it must be calling exec() or execve(). So virtually every action related to the system is directly interpreted as system call. This is the basic idea why tracking based on system calls can be a tough weapon. Interested Then you can give it a try. In this article I use Redhat Linux 7.3 as a base system. Just point your browser to http://syscalltrack.sourceforge.net and download the package from the download section. For this article I use syscalltrack-0.82.tar.gz with approximately 500kB in size. Unpack this package in a directory let s assume in /usr/src: # tar xzvf syscalltrack-0.82.tar.gz And then verify that you have the Linux kernel source code at /usr/src. # rpm -qa grep -i kernel-source OR # ls -al /usr/src/linux-2.4 If one of them gives a negative result then you need to install them. It is on Redhat CD (#2): # rpm -replacepkgs -Uvh /path/to/your/RPM/kernel-source-2.4.18-3.i386.rpm Pay attention that you HAVE TO compile Syscaltracker based on same kernel version (and other additional patches) that your Linux system is currently running. For example: if you use a standard RedHat 7.3 kernel then you have to compile with the kernel source from the Redhat CD. Or if you want to use your own Linux kernel later on the you must compile Syscalltracker based on this kernel source. Besides kernel source code to ease Syscalltracker compilation you also need the kernel configuration file from Redhat. Try to check the content of /boot: # ls -al config* If there is an output like config-2.4.18-3 then you need to copy this file to /usr/src/linux-2.4. Rename it to .config # cp /boot/config-2.4.18-3 /usr/src /linux-2.4/.config If this file is somehow missing the you can copy it from kernel source directory. It is located under the configs directory. You must pick one that matches your currently running kernel. So first find it out with # uname -a What you are runn

INFO HASH : ea05775836fa128c82b92a07e4696e4b410868d5

Download now

File Size: 43.4 kb