Security of packets in NSM tools

The basic scenario is the following :

An intruder gains root access to one of your sensors containing full packet captures. What now ?

We can all agree that the repository of packets represents significant business value, otherwise we’d all be sharing our pcap dumps on github. Therefore a breach of this nature can hurt. At a minimum, it can enhance the intruders social engineering targeting by observing behavior of key personnel. In the worst case, they can directly carve out all the documents sent over the network in the applicable time window.

What are the available options in addition to extra access controls to the sensors ? Lets consider two of them

1. Full disk encryption
2. Per file encryption

Full Disk Encryption (FDE)

Systems like TrueCrypt enable transparent access to an encrypted volume. None of the applications need to be modified. With FDE you are saved against guys getting their grubby hands on decommissioned disks. While theft isnt a likely scenario in large organizations, it is very real for smaller ones. Storing packet captures or sensitive BRO-style HTTP logs on FDE volumes can protect the most obvious physical threat. This does not however help against an intruder on a live system. They have the freedom to run the entire gamut of PCAP tools against your data.

Per file encryption

In this case, each packet capture file or directory is encrypted. So a bad-fella who drops in as root into one your sensors has the unenviable task of figuring out how to decrypt the content. The obvious question is “Well, if there are tools on the machine which can decrypt, the intruder will use the same tools”. There is a way to address this concern, it isnt perfect or pathbreaking, but it goes like this. We use Trisul as the reference here but other tools can adopt this too.

Trisul does a per-file encryption for all capture files using AES-128-CTR. If you are running Trisul you can find the content files (named RCF_xxxx ) here :

Copytrisul@trisul-east1:~$ ls  /usr/local/var/lib/trisul/CONTEXT0/caps/oper/
RCF_triscap.0Lkajl  RCF_triscap.aPNBZh  RCF_triscap.Gu7vJM  
RCF_triscap.mgg16l  RCF_triscap.T7RvYt  RCF_triscap.0p9AcI 

The passphrase is stored in a simple text file. The idea is we will secure access to this file.

Copytrisul@trisul-east1:~$ grep PassphraseFile /usr/local/etc/trisul/trisulConfig.xml 
<PassphraseFile>/media/TPASS/trispass.txt</PassphraseFile>
trisul@trisul-east1:~$ cat /media/TPASS/trispass.txt
Trisul eats packets for breakfast,lunch,and dinner.

The following executables need access to the passphrase.

1. trisul – Main server. Only encrypts.
2. trisul_dpitool, _drilltool, _greptool, TRP etc – Packet analyzers. Only decrypts.

A human admin needs to help out with the following

• Put the passphrase file on a USB stick or TrueCrypt volume of its own
• Mount the volume during Trisul startup (not frequent)
• Mount the volume whenever one of the analysts wants to pull out packets (how frequent?)
• Unmount the volume at other times

Summary

The intruder could just wait around for the volume to become available and then get involved. However polling /proc/mnt or using inotify carries a risk of being detected for the intruder. In addition, the tools are designed for targeted drilldowns/searches so it is difficult to export the entire repo to tcpdump format without detection. The scheme isnt foolproof but Per-file encryption along with Full Disk Encryption can significantly bolster your defenses.

Happy NSM-ming.