8.1. Packet Capture Basics
The Trisul raw packet engine is designed towards these goals :
- Scaling — The amount of data is only limited by the disk resources at your disposal
- Multi disk — Supports multiple disks to optimize $/byte
- Flexibility — Allows you to specify policies to cut down storage requirements
- Security — Encrypts the raw packet storage
Note that the free license only allows you to store a maximum of 10GB per Probe. You can use rules to cut down the traffic, such as not storing encrypted traffic.
8.1.1 Sliding slices
Trisul uses an innovative sliding mechanism to store raw packets.
Raw packets are stored in three directories.
|oper||Operational slices||recent data that is most likely to be called up|
|ref||Reference slices||not so recent data so okay to be on slower disks|
|archive||Archive slices||unlikely but may be called upon, could be on slower disks|
As each directory gets filled up, the oldest slice from that directory moves to the next area. Slices from the archive silently move to
/dev/null(they are deleted). The figure below illustrates the concept. Note that trisul only writes to the oper slices.
You have to edit the following parameters to suit your environment.
- Size of each slice (file storing raw packets)
- Number of slices (files) in oper, ref, and archive areas
See the trisulConfig.xml documentation for more details.
8.1.2 Mapping disks to slices
The slice architecture allows you to configure hardware resources for peak performance. The concept behind the optimization is :
- Older data less likely to be called up than recent data
- If older data is called upon a reduced performance is acceptable
- Writes only ever happen to operational oper slices
With these in mind, you can save money while getting peak performance by mapping faster disks to the operational area. An example is shown below :
8.1.3 Flexible policies for volume reduction
Storing raw packets can be tricky due to the volume of storage required. Not every organization has the resources to store absolutely everything. In our experience, there is always some trusted and predictable activity that allows scope for optimization. For example :
- a daily full company offsite backup
- Antivirus pushes from a trusted server to desktops
- lots of very long flows – such as MSDN / Linux ISO image downloads
The primary method Trisul uses to cut traffic is rule based flow capping. You specify a chain of rules and the disposition when each rule in the chain matches.
A sample rule chain is shown below. We want to :
- Cap av-pushes to first 10M
- Cap lotusnote traffic to first 1M
- Do not store traffic to offsite-backup
- Store full content for everything else
Rule chain :
8.1.4 Encrypted content
Raw packets represent all of your network communications over an extended time period.
Storing them in the clear :
- makes Trisul an attractive target for attackers
- makes disposal and reuse of disks risky
- makes enterprise network admins nervous about such systems
Trisul encrypts all content by default using AES-128 in CTR mode. The disk subsystem never sees clear text packets.
To change the passphrase, see the PassphraseFile parameter in trisulConfig.xml