Classnotes | UNIX03 | RecentChanges | Preferences Once you have detected that your system has been broken into, it would be very helpful to try and find any running processes that the cracker has left behind. Remember that any program on your system may be compromised.
It is preferable to operate as a non-privileged user that does not have access to anything important. This is because there may be a trojanned or otherwise compromised program on your machine waiting for an administrator to come along and trigger it.
It is advisable to keep a "stealth" version of ps under an unassuming name. If you run an application, call it by that name. Do a ps of your system and note root programs such as lpd and sendmail as possible names to call your "stealth ps" executable. Some crackers might notice that sendmail should not have an argument of axlww so if you are feeling ambitious, grab the source of ps and tweak it to create a custom version that defaults to these flags. To recall what these flags do:
The "a" flag requests all processes
The "x" flag also includes daemons
The "l" flag requests long format
The "w" flag allows longer lines
The second "w" allows unlimited lines
For now, let's assume that you have found a suspicious process, /bin/ls. You are suspicous of /bin/ls because it has been running for a long time and there is no reason for a user to be doing something like
/bin/ls -R /
The PID of /bin/ls is 16887 so you use your covert ls command, say, monthly, to issue the command
# cd /proc/16887
(taking us into the proc filesystem for this PID)
# monthly -l
and it might show
-r--r--r-- 1 root root 0 May 17 00:49 cmdline
lrwx---r-- 1 root root 0 May 17 00:49 cwd -> /tmp
-r-------- 1 root root 0 May 17 00:49 environ
lrwx---r-- 1 root root 0 May 17 00:49 exe -> /tmp/.genie
Observe that the exe file is a symlink to the executable program that was invoked and it certainly does not point to /bin/ls. Very likely, this is a Trojan horse. Note that because these files are owned by root, this process is running as root. You could do a binary comparison with the real /bin/ls to convince yourself that it really is a different program:
cmp exe /bin/ls
The following output would be typical:
exe /bin/ls differ: char 25, line 1
Clearly, it is a different program. This is a Trojan horse.
At this point, you want to make a note of the PID of this Trojan and its executable name. You will also want to make a copy of this Trojan horse, preferably to some external media where it can be analyzed later (such as a CD, floppy, or zip disk).
Now you have several options regarding how to proceed and there is no one right answer. You could simply kill the process. You will want to do a kill nasty on it and not a simply kill (as that will just signal it to die, and it does not have to obey that):
# kill -9 16887
A really good cracker will have another process monitor this one and detect when it dies. The book goes into detail using the GNU Debugger to analyze files for this situation. We will not go into it in this course.
The program could also be waiting for the cracker to connect to it via UDP or TCP. So let's not kill the program and instead take a look at the files it has open:
File descriptors 0, 1, and 2 are stdin, stdout, and stderr- all pointing to /dev/null (meaning, the program is running as a daemon). But file descriptor 3 is a network socket. We could issue a netstat -avp command and get something like the following:
Proto Recv-Q Send-Q Local Address Foreign Address State
...
tcp 0 0 *:1234 *:* LISTEN
...
Running the ports program we covered on the first day we get confirmation that this is a Trojan horse from its default port number.
This example shows the basic processes involved in performing live-analysis on a compromised system. In this case, the trojan was one known as subseven. For a detailed view of some other popular trojans, take a look at pages 680-682 of the book.
