Computer Forensics

Craig Maloney writes "Many Slashdot readers know how to secure a network, and many know how to determine if a security breach has taken place. Fewer readers, though, would know how to handle a security breach if corporate assets were involved. How would you cooperate with law enforcement when a crime has been committed on a computer?" For more questions, and the rest of Maloney's review of Warren G. Kruse II and Jay G. Heiser's Computer Forensics, read on below. Computer Forensics author Warren G. Kruse II and Jay G. Heiser pages 392 publisher Addison Wesley rating 8/10 reviewer Craig Maloney ISBN 0201707195 summary A good reference for what to do when computer crime happens

How do you get the evidence off of a computer, ensuring that it's capable of withstanding a defense lawyer's scrutiny? Maybe you would just unplug the machine and put it in storage awaiting a detective's arrival, but is that what we should do? What if the evidence is on a production server that can't be simply unplugged and put into storage? What if that evidence is slowly being erased as files are created and deleted on that server? How do you help build the case against a computer criminal? Hopefully you'll never have to worry about computer crime in your home or workplace but if you do have to worry, Computer Forensics will be an asset to your part of the investigation.

Who is this book for? Computer crime isn't simple -- it can range from damage done by simple script kiddies to corporate espionage by disgruntled employees, as well as sophisticated, multi-homed attacks by skilled crackers. Computer Forensics tries hard to cover a lot of these areas. The book includes a chapter dealing with laptop hardware, as well as ones on data hiding and encryption, and further chapters on putting evidence together and dealing with law enforcement. While these topics may be of interest to the Slashdot crowd, Computer Forensics focuses more on broad topics of interest to computer detectives faced with getting up to speed quickly with computer crimes and computer evidence gathering.

Several chapters are downright boring for anyone who has a modicum of computer experience. Finding out where e-mail is stored on Windows and Linux machines, or understanding what a root-kit is and what it does will be pedestrian for many readers. Nestled away between the necessary-but-pedestrian topics, though, are some very useful tools. The authors use netcat with tar to copy files between machines without disturbing the modification times (something I would never have thought to use). Novice users will find a wealth of tools and examples in these chapters. The tools used in the book tend toward open source and free tools, and rely heavily on Linux as the Swiss Army knife for handling file systems and files without disturbing them. Any reader should be able to put together a decent set of tools from this book.

Making it all work

Putting together a good forensic kit is all fine and good, but making sure your evidence holds up to the scrutiny of some high-powered, high-priced defense lawyer is much more important. The last chapter of Computer Forensics gives a brief introduction to the criminal justice system. The authors touch on notifying law enforcement agencies, search warrants, probable cause, interviews, subpoenas, dollar loss guidelines, and testifying as an expert witness, among other legal topics. The appendices of the book have checklists, flowcharts, and an incident report form to aid investigation and evidence gathering. These are invaluable resources for the system administrator of any public machine who needs to deal with law enforcement.

Conclusion Thinking about dealing with courts and law enforcement may not be at the forefront of any administrator's job, but it is a reality any administrator needs to think of and be aware of. Computer Forensics will at least make administrators more aware of what their legal options are, and of the form in which gathered forensic data needs to be presented as evidence. Computer detectives will find a good, if not rudimentary example of what to look for when investigating a computer crime scene. This may not be the most comprehensive book on the subject of computer crime, but it will point you in the right direction to help investigate it should it ever happen to you.

You can purchase Computer Forensics from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

SecurityFocus

[ProfaneBaby]

The security focus mailing list dedicated to forensics is also good lurking, for those interested...

http://archives.neohapsis.com/archives/sf/forensic s/

Enterprise file forensics

[Anonymous Coward]

We use Dynacomm i:scan in our enterprise and it basically does all the forensic work for us. Kinda spooky the things it can report and notify on.

Re:Enterprise file forensics

[anomalous cohort]

There is a folder full of forensics tool on the knoppix security tools distro. There are tools like sleuthkit 1.66 which is supposed to be an extension to the coroner's toolkit. Has anyone here used these tools? If so, do you know if the results from these forensics tools are useful and/or admissible in court?

Re:Enterprise file forensics

[LordDracula]

If so, do you know if the results from these forensics tools are useful and/or admissible in court?

Admissibility is not so much tied to the specific tools (though this can be an issue; more on this later) used, but the methodology used.

DISCLAIMER: I am not by any means a forensics expert, but I am doing an independent study in computer forensics in college.

That said, many of the standard *nix tools are, in fact, acceptable for court use. For example, it is extremely unlikely that you will have a challenge presented in a courtroom questioning the integrity of your forensic duplications if you used 'dd' to make the images. At least, not on technical grounds--failure to document everything correctly and completely could wind up causing inadmissibility.

I'd strongly recommend Incident Response & Computer Forensics by Mandia and Prosise (of Foundstone, Inc.). This book has a LOT of technical information, and covers the aspects of evidence handling, documentation, etc. very well.

Looking at some of the tools listed in the Knoppix STD, I can say that many of them (like fatback, foremost, dcfldd, and cryptcat) are recommended tools in the Mandia/Prosise book. I've used each of these, and they are all definitely useful. If you're doing work that must stand up in court, however, make sure you document everything you do, and never, never write anything to your suspect drive! Doing so will not only risk losing evidence, but also invalidate the entire drive as evidence. All forensic analysis should be done on either a qualified forensic duplicate or full forensic duplicate.

Time sync all your computers

[uid100]

OS level Forensics are much easier if all your computers are set to the same time.

There is no (good) exuse for not at least NTP'ing all your servers.

Re:Time sync all your computers

[Panaflex]

That's totally true.. in fact have every maching on your network NTP'ing. I've worked on a few compromised servers. Of course the first step is to NOT GET COMPROMISED. Use tripwire, honeypots, and protect yourself.

One thing people forget about is getting the STATE of the server before you off-line it. I'd suggest getting packet dumps, network routes and connections.

REMEMBER:
1. Load up a live CD with some KNOWN GOOD utilities, set the path to $CD_PATH:$PATH so it searches off the cd first or specify the full path of the utility on cd.
2. Capture processes & threads, routes, sockets, and adapter info, and perhaps a packet dump if things are active into a text file and store somewhere safe.

YMMV

Panaflex

Transfering for forensics

[Kalak]

Rsync will do this simply and efficiently, plus it can resume transfers and also tunnel through ssh.

Also you can pipe dd through gzip/bzip2 and netcat to give you a loopback mountable, unmodifiable image that you can look at in case you want to grab the whole drive before putting it in the evidence locker.

Re:step 1...

[Anonymous Coward]

If you're that worried about having anything behind your firewalls compromised, you're usually not going to give that information to MS. Rather, send complaints to whoever sold you your broken firewall software.
Oh, and if it's because of an email-based virus or some such problem, fire your security team and sysadmin, they don't know what they're doing.
You should know better than to randomly make digs at MS. Yes, they have security holes. I know you don't like IE. But Firefox too has had its problems, as has pretty much any other browser. That's why we patch them. Really, if you're running a box that hasn't been patched in months or years (regardless of OS), have an ineffective firewall, or have no firewall at all, you deserve everything you get. Windows and any Linux distro should be logically equivalent from a user's standpoint. You can make a Windows box as safe on a network as you can Linux, BSD, OS X, or any other OS. Windows has end-user control like you would find on any UNIX-based system. It's called GPO. It allows you to set rules as to what users can and can't do (think: installing software, writing to the registry). This stops pretty much all adware, spyware, and malware in its tracks, as you would have to manually start it each time you start your system. Throw in some AV software for an extra layer of security, patch your systems with SMS, and you're set. Now, pretty much any OS will have similar tools. People tend to use those tools more frequently when they're not using Windows, for some reason. Can you blame MS for writing tools that aren't used by lazy sysadmins?

Re:Outside the U.S.

[Umbral Blot]

Many books on security are a double edged sword. For example a tutorial on creating protection mechanisms in your programs against disassembly at the same time tells you how to break those protections. A book on how to detect and remove virii gives you insight on how to make them. I could go on... I think the point is that the "bad guys" will leard this information anyways, so we might as well give the "good guys" the same information, especially since the "good guys" don't spend all of their time trying to compromise security.

Department of Justice Forensic Guide

[greyfeld]

Here's a link to the Department of Justice's Forensic Guide for Law Enforcement if you are interested.

http://www.ncjrs.org/pdffiles1/nij/199408.pdf

Re:More importantly...

[Pompatus]

1) Put a password on your bios. Someone will have to do some fancy soldering to replace it if they want to boot your machine without your password.

Unless you did some REALLY fancy soldering to set that password, simply removing the battery from the motherboard for about 10 minutes resets a bios password.

2) Store all sensitive data on an encrypted medium. Just hope no one puts a key logger on your keyboard.

That all depends on the strength of the encryption you use and the strength of the computers trying to break it. (to give you credit, this is probably the best idea you propose, if it is properly implemented.)

While being quite secure is as simple as installing *nix, .....

This is the one that really bothers me. You have to actually CONFIGURE your *nix to be secure! It doesn't just magically happen. And after you have it configured, you have to stay up to date with the programs you run in order to avoid the latest exploits.

It's important to understand that you can't just do some work on a computer and then sit back and say, "there, now it's secure forever". It's also important to understand that given the proper amount of time, nothing you do will secure your computer if someone has physical access to your machine.

not to name names

[bani]

"intel"

the ex-employee is David Dugan.

the case you're talking about is this one:
http://www.theregister.co.uk/2004/11/11/inte l_gun_ man/

Re:Step 1

[towaz]

I would not just kill the machine yet either. As long as you document your findings and what you do to the system (with witnesses) you can do a few things first.

On the live system you can not trust anything so a cd or other media containing your tools statically compiled to investigate are needed.

you can use dd to make a bit for bit copy of ram, pipe this through netcat to your forensics box, or cryptcat is sensitive info is on the compromised machine.
A good idea would also be to calculate an md5 checksum for the image either side of the netcat pipe to verify its not messed up.

then run lsof to check what ports are open and by what applications and pull the plug out the wall on the compromised host.

then make sure boot priority in the bios does not boot the hdd in question and run knoppix or something like F.I.R.E and run md5 on the drive, pipe it to your machine with nc and then md5 that image.

I know i missed something but am on the phone so i guess will wait to get flammed :)

A 'thank you' from the SF forensics moderator...

[sczimme]

The security focus mailing list dedicated to forensics is also good lurking

I am the moderator of the SecurityFocus.com forensics list, and agree that it is a great resource. (Al Huger is listed in the info page as the moderator; he is actually the list owner.) The list is dedicated to discussion of technical forensics topics.

The SF forensics list archives are here. A general listing of SF mailing list archives is here. Those interested in subscribing to the forensics list (or other lists @SecurityFocus) can do so from the archive page.

Cheers!

Scott C. Zimmerman, CISSP