By Bri Hatch.
Summary: It is imperative that you can determine what state a machine was in before you can ascertain how crackers compromised your security measures.
When your machine is cracked it's a good idea to figure out exactly what happened. If you don't know what was or who was on your machine, there's little chance you can ascertain what occurred to breach the security. Regardless of your post-compromise preference (fixing the problem or reinstalling from scratch) it's imperative that you understand what happened. If you end up leaving the exact same vulnerability open, you haven't fixed anything.
For example, I once consulted at a pharmecutical company that was required by FDA regulations to keep detailed paper logs of every piece of software installed, every configuration change, ever user added or removed. While most of us grumbled about the annoyance of doing so, it made it absolutely clear what the state of a machine was over time, which made it easier to correlate problems with configuration changes, and find other bugs created by users^H^H^H^H misconfiguration.
Unfortunately, most folks don't have the time or energy to list everything they do to a system. However there are many steps you can take to make things more automated.
This article is written partially in response to a request from a reader. He found that several processes were running as uid 1032, but no such user existed on the system. In fact, more processes kept being run over time - it wasn't just leftover processes that were still running. It took a while to track down how the processes were being started before they were all killed off.
There used to be an actual user with uid 1032, but it had been deleted some time in the past. Since the record from /etc/passwd was gone, it was not immediately obvious who the user himself actually was.
Next week I'll teach you a very simple trick you can use to lock out user without loosing their actual login information. However until that time, I offer my latest challenge...
 Yes, "when", not "if". Sooner or later, it happens to all of us.
Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He is a bit CVS-happy. His websites are all stored as WML in CVS, and any cvs commit automatically triggers a rebuild of the site and rsync to the webservers. Now if only he could get this to work for the non-computing areas of his life. Bri can be reached at firstname.lastname@example.org.
Copyright Bri Hatch, 2002
This is the November 06, 2002 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Securityemail@example.com.