Snort and Investigations | Monitoring Network Performance

Table of contents:

Snort as Legal Evidence in the U S

Problem

We have been using Snort for some time as our IDS platform. But now that we have a criminal activity that we caught, how do we help/assist law enforcement with our logs?

Solution

The first thing a government or military law enforcement investigation will ask is: how many people have access to the data? The next question will be: has the data been changed by anyone?

These are only some of the questions that will be posed to you by an investigation team. The other thing to keep in mind is that you should have your detection policy and methodology documented in your procedures. This is especially important in investigations involving someone's privacy. For example, you might have a documented procedure of detecting porn on your network with generic keyword searches. If you find a user breaking the policy, the documented procedure will back up your team no matter who the user is. Unfortunately, it really does happen: high-ranking employees you catch violating corporate policy may turn and accuse you or your team of violating their privacy rights. A documented procedure protects your company and your CIRT team from being sued.

The second point worth making is that different law enforcement agencies will want different types of data. The level of interaction between your team and theirs will also vary with each incident. Your documented procedures should help maintain the chain of custody as well as the chain of evidence.

Discussion

One of the easiest ways to help a law enforcement group is to hand them your documented processes and procedures. This can help them for several reasons:

They understand the function and mode of operation for your team. This can help them frame how/why you brought the event to their attention.
They understand who has access to your data. Does your IDS data lie out of band? Who can read/see the data? Encrypted data paths from your sensors to your backends are good.
They understand what kind of data to ask for. If your procedures say you can't keep full TCPDump logs due to having a high-speed, high-bandwidth network, they know they are only going to get session and/or single-packet alarm data, such as from Snort.

One suggestion for teams that have to deal with law enforcement quite often, such as ISPs or government/financial teams, would be to sign/encrypt your logs. For example, if you rotate your Snort alert file every 24 hours, what happens to the old file? Is it kept? Where? Is it moved offline?

If you keep the old logs on the sensors, why not sign the files with md5 hashes, for example. Then take the hashes to be stored on a write-only file/media on, say, the backend device(s). For example in the following script, we create a hidden file on the sensor that should have the same hashes as the file on our backend, so when we go to collect the logs for the date in question for law enforcement, we can show that the files haven't changed since they were collected, and no one has been able to easily change the data. (Or at least the data can't be changed easily, because someone familiar with your system could simply recreate or delete the files. However, if your sensors and backend are compromised, you have bigger problems to deal with!)

The following script could be used to help generate law enforcement-friendly logfiles. This script is run as a nonprivileged user scripts while using encrypted scp to transfer the logfiles. This script is called once a day via cron at 11:55 PM from the sensor.

55 23 * * * /bin/sh /scripts/IDS_SEC.sh > /dev/null

This script creates the hashes of the valid files, and then copies the file to the server and a hidden directory on the sensor. However, for high traffic or high-security networks, being called once an hour might be more appropriate.

# The script could look like this 

#!/bin/sh 

#

# Variables 

mydate=`date +"%m%d%Y" `

 

# remove any possible old file 

rm -f /tmp/hash.txt 

 

# create the new temp file 

touch /tmp/hash.txt 

 

# sign the new one 

md5 /log/snort/alert.10052004.gz > /tmp/hash.txt 

md5 /log/p0f/pof.log.10052004.gz >> /tmp/hash.txt 

md5 /log/snort/session.log.10052004.gz >> /tmp/hash.txt 

 

# now send the hash to the backend 

scp 10.0.1.1:/log/SENSORS/sensor1/SEC_LOG.$mydate /tmp/hash.txt 

 

# write the hash file to a hidden file on the sensor for dual check

 

echo "LOGS FOR $mydate" >> /root/.SEC_LOGS 

cat /tmp/hash.txt >> /root/.SEC_LOGS

 

# remove the evidence 

rm -f /tmp/hash.txt 

 

# All done!

This can apply also to your Snort "tagged" sessions as well as for your TCPDump logs, the simple point being: if you can show that your documented IDS procedures tell you to automatically sign your logfiles and the logs haven't been touched since they were written, then law enforcement will have an easier time showing that the data was collected and held in a manner close to a chain of evidence. While non-law enforcement personnel aren't held to as high a standard as law enforcement, this will help in an investigation.

Another example is if you have IDS data in a database, such as for ACID. Law enforcement personnel need to be shown that the data can be inserted into the database only by one means, the sensors, while the data can be sorted, organized, read, deleted (depending on the organization) from only one other method. Another help is to show how the data travels from the sensor(s) to the database. For example, if you are using the encrypted SSL/MySQL recipe from Chapter 1, then unless an attacker is between your IDS sensors and backend with an SSL decrypting/re-encrypted device, he can't see/tamper with the data. If once your IDS data is inserted into the database the data is encoded, such as with a base64 algorithm, it's not simple to change or remove the data cleanly without leaving a trace of evidence to track with.

This can be set in the snort.conf, file as in the following:

# snort.conf file example 

output database: log, mysql, user=snortuser password=password dbname=snort

encoding=base64 host=localhost sensor_name=sensor1

When combined with the native encryption of MySQL/OpenSSL, you now have shown that the data can't be tampered with very easily.

Finally, if you can demonstrate that your procedures document the attempts at maintaining a secure, verifiable log infrastructure, most law enforcement and legal teams will be able to testify/use your data with a level of confidence.

While keeping this in mind, remember that your procedures and policies will provide your team and organization with the top-cover that you need when law enforcement is called in and your data is put to the test. If you maintain this secure infrastructure without having it documented, law enforcement and the legal system may not be able to use your data. For example, at a previous employer, we were able to gather some information about some network traffic that was not really outside our procedures, but more like a side-step. When we handed the data over to law enforcement, they thought it was great until the officer in charge asked us how we got the data because it didn't look like anything we had documented. It turned out they couldn't use the data, and so we had to prove otherwise that the attack had indeed occurred. Now we went back after the fact to change our procedures, but the damage was done. Remember that each law enforcement agency is going to ask for different types of data and just work with them best you can for each situation.

Snort as Legal Evidence in the U S

Installing Snort from Source on Unix

Logging to a File Quickly

How to Build Rules

Detecting Stateless Attacks and Stream Reassembly

Managing Snort Sensors

Generating Statistical Output from Snort Logs

Monitoring Network Performance

Index