Real World Linux Security: Regaining Control of Your System
- 1 Finding the Cracker's Running Processes
- 2 Handling Running Cracker Processes
- 3 Drop the Modems, Network, Printers, and System
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In this chapter, techniques are explored that enable you quickly to regain control of your system after having discovered that someone has cracked it. This can be a delicate and complex operation if you are to minimize damage and maximize the amount of knowledge to be learned about what happened and how. Because you are dealing with unknown software (the cracker's), there is no one right answer and there are no guarantees.
Part IV should first be read before you actually suffer a break-in, so that you have an understanding of what to do to recover and have made some preparations in advance. On a test system, conduct some practice sessions recovering from a simulated attack. Some suggestions on how to do this are offered in "Fire Drills" on page 462.
Plan to disable important credentials quickly. This includes PGP, SSH, and SSL keys that might have been compromised. Change any passwords that might have been compromised through sniffing or social engineering. If the cracker might have gotten control of financial systems that print checks, ship merchandise, handle credit cards, or the like, be sure to block the flow of goods and money. This might include closing bank accounts, stopping outgoing shipments, etc. until a detailed analysis is completed.
The topics covered in this chapter include:
"Finding the Cracker's Running Processes"
"Handling Running Cracker Processes"
"Drop the Modems, Network, Printers, and System"
18.1 Finding the Cracker's Running Processes
Once you have detected that your system has been broken into, it would be very helpful to try to find any running processes that the cracker has left behind. Remember that any program on the system might have been compromised.
It is preferable to operate as an unprivileged user account that does not have access to anything important. This is because you do not know what programs have been compromised. For example, perhaps the cracker discovered that /usr/local/bin was mode 777 (world-writable) and he placed a compromised version of date in it. He might be waiting for something as innocent as root invoking date to get full control of the system—that is, "own it" in cracker parlance. By operating as that unprivileged user, clearly you limit the consequences of this or other actions.
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. (The "a" flag requests all processes, not just yours; the "x" flag also includes daemons not associated with a terminal; the "l" flag requests long format to give more details; the "w" flag allows longer lines; and the second "w" allows unlimited lines.)
Back during my gray hat student days at Berkeley, one time I was operating covertly as root, repeatedly doing a psa to watch for system administrators trying to detect us. I was "riding shotgun" while Doug Merritt installed a Trojan.
I noticed someone logged in on an administrator account do a ps and knew that we were detected. Twenty seconds later the administrator was using the write command to contact me, asking who I was.
Fortunately we were in a little-used terminal room and we were logged off and out of Evans Hall in 60 seconds flat! The lesson is that each side in this war should have been using stealth versions of ps. The better crackers now do this; you should too!
18.1.1 Handling Deleted Executables
One cracker trick is to remove the executable of a running program from the file system. Recall that this will cause the reference to the name of the file in its directory to be removed but the file still will exist until all programs that have the file open (as open file descriptors) close it.
A running program "in execution" is treated as an open file. Crackers know that the first thing most SysAdmins do when they detect an intrusion is to shut down the system, either to copy the disk for evidence or analysis or in the hope that the problem will go away. Of course, on a clean shutdown the program's execution will be stopped and the program's data blocks and inode freed. If the system is shut down abruptly, the cleanup will be done upon reboot by fsck.
The method for detecting these executing programs and making copies of them automatically (for analysis) is discussed in "Detecting Deleted Executables" on page 517. Any of these executables that are found are almost certainly Trojans, unless one of them is a program under development by a programmer whose building of a new version caused the deleted version to be removed from disk.
A very useful feature in the kernel is that the symbolic link in /proc to the executable is good even though the original file has been removed from the file system! This allows you to make a copy of the file for analysis as simply as
cp /proc/479/exe /home/samspade/del_cracker
In other words, if the cracker did
cd /tmp .genie& rm .genie
this technique still will recover a copy for you to analyze and present as evidence.