Collecting Evidence

Your log files are the best evidence you can collect to track attacks against your system and use for prosecution in the off-chance that you get authorities to track, capture, and prosecute an attacker. Yes, that does sound like no one cares about your computer, but the reality of home system compromise is that no government agency cares enough to help you. It's up to you to protect yourself and stop the attackers. In that case, you probably don't have to worry much about collecting evidence of an attack for legal prosecution, but you should know the basics behind collecting evidence like corporations do for prosecution.

Collecting all log traffic and attack signatures is a time-consuming and tedious process. You have to save all the data to some form of backup media and be thorough over a lengthy period of time for the evidence to be worthwhile. The main reason you as a home user should collect evidence of attacks is to educate yourself about how people view your presence on the Internet. By educating yourself about attacks, you can prevent future attacks and modify your firewall filter rules to protect yourself. If you know where you are potentially vulnerable, you can fix holes before they become a real problem. Watching what happens in your evidence logs will help you determine the current flavor of attacks that are being used.

If you choose to collect attack data and compromise evidence, you will be collecting data both before and after a compromise. It's easy to understand why you want to collect data before you are compromised. All that attack data will help you stop future attacks and make sure you are not vulnerable currently. What happens when you have been compromised? Do you take your computer off the network? Do you let it keep running and give the hacker continued access to your system? First, if you pull the computer off the network, you might lose the opportunity to see where the attacker is connecting from, what data he is transmitting, or why he is using your system. To see where he is making a connection, you can use a program such a Vision (www.foundstone.com). In Figure 16.4, we see that several remote IP addresses are listed. If an attacker compromised your system and made a remote connection to another server, such as to FTP files from your computer, you would see it listed.

If you wanted more detail, you could use a sniffer program to capture traffic in and out of your network. You could watch exactly what data was being transferred back and forth by the intruder. The problem with that is that you would run the risk of alerting the intruder that you knew of his presence; the intruder has full control of your system and watches the processes running just as you do. If the intruder sensed you, he might then wipe all traces of the attack or destroy all your files.

It is a risky venture to leave the system up and running after you have been compromised. Do the benefits of watching the intruder outweigh the risk that he will destroy your files or get all the information he wants from your system before you stop him? On the other hand, if you immediately disconnect the system from the network, you run the risk of losing valuable logging information. You might not be able to determine where the intruder connected from. If he hacked up some other system to get to yours, you could possibly find the ISP he belongs to and notify the ISP or the owners of the hacked system. By disconnecting immediately, you run the risk of not being able to track down the attacker.

As we have already said, the benefits of collecting data as a consumer are miniscule. You probably won't be able to prosecute anyone. The most you can do is notify the ISP of the hacker and his activities. If some company or university has been hacked and is being used as a launching pad, you can notify them that you are being attacked by one of their systems. Because many good attackers do not use their own system from which to hack, you probably won't be able to trace them back. Script kiddies use their own cable or DSL connections, so it's easy to notify their ISP of suspicious activity. The evidence you collect could be used in criminal prosecution if you collected it correctly and you were able to get law enforcement to track the attacker.

You can collect several types of evidence:

• Real evidence— These are actual logs of hacker activity that are not modified by you in any way that can be shown. This is the only evidence that really will hold up in a hacking case.

• Testimonial evidence— A witness provides this type of testimony. This is perceived reality (what they think happened), and the witness must testify.

• Hearsay— Someone who is not a direct witness provides this testimony. It is not reliable in court.

Five guidelines exist for collecting electronic evidence:

• Admissible— This evidence must be good enough to be used in court.

• Authentic— The evidence must relate directly to the incident.

• Complete— You have to show both the activity of the hacker and the activity of others on the system or network to prove it wasn't someone else doing the hacking.

• Reliable— The method you use to collect and analyze the data must be reliable so that the authenticity and veracity of the data is not in doubt.

• Believable— The data you provide must be understandable by a jury. If the jury cannot understand what the evidence shows, then you cannot prove anything.

Because many functions are performed by a running system, in the applications, in the operating system, and in memory, evidence and logging can change by the second. If you are serious about collecting evidence of a break-in, you have to collect all the information from applications, the operating system, and what is in memory. This is by no means an easy feat. You must minimize any chance of corrupting data; you can do this by shutting off the computer or disconnecting the system from the network. You should keep a copy of all your evidence, and it should remain untouched. All the actions you take from the moment you determine that a break-in has occurred should also be logged and recorded. The time of events is important as well. If you need to reconstruct events or chain actions by the attacker together, you need an accurate timeline. If you are working on a system that is currently compromised, you have to be quick about collecting evidence. You don't know what the attacker will do next, and you probably don't want more of your data to be accessed than has been already.