Pulling packet capture from IPS device

Question

I work for a MSP (Managed Services Provider), we currently are evaluating CSM for mgt of 50 IPS/IDSM devices. To make analysis more effective, want to be able to pull the packet capture from the device. We have our own correlation engine, so we do not need MARS. We want to grab the packet and then put a copy into our ticketing system so the analyst has the data right in front of them.
Is the IP Log directory where the packet capture data is kept? Has anyone ever tried this before? What are the performance/health concerns with enabling packet captures for just high signatures? Does the IP log directory really "clean" itself out after a certain period of time?

Answer 1

There are 4 event actions that can be used to capture packets.
The produce-verbose-alert event action will encode the trigger packet as part of the alert itself. So with this event action the packet is already included in the alerts you are already pulling off the sensor. You just need to modify your tool to strip off this packet, decode it, and then add it to your ticketing system at the same time as you add the alert.
This is where I would start.
Using the produceVerboseAlert uses very little additional sensor resources. It has only a very small affect on sensor performance. Because each alert will be larger than normal it will reduce the total number of alerts that can be stored in the sensor's eventstore. But if your application is actively subscribing for these events, then the reduction in total number of alerts stored on the sensor should not cause you any issues. So adding this for all High alerts woulc be a good practice.
The other 3 event actions are log-attacker-packets, log-pair-packets, and log-victim-packets. These event actions will trigger an IP Log (packet log) to be created (or increase the time for capture on an existing IP Log.
The IP Log system is a collection of numbered files on the sensor. As event actions trigger new IP Logs to be created the sensor will pick one of those numbered files and begin writing packets to that file. The sensor retains an internal mapping of what packets are being written to each file. If no empty files exist, then the sensor will automatically overwrite the oldest IP Log file with the new IP Log file. Larger platforms have up to 512 of these numbered files, and smaller platforms may have as few as 128 or even 64 of these numbered files. Each file is 1 Megabyte in size and usually stored in RAM memory. With the limited number of files, the storage of these logs on the sensor is very short term. And so should be pulled off the sensor as soon as possible (just like what you are planning to implement). The sensor also has a usual limit of only writing 20 IP Log files at any one time.
With these limitations on the IP Log files they shoudl be used sparingly. Configuring too many signatures or signatures that trigger often with these event actions can lead to problems. The IP Logs could easily be overwritten by newer IP Logs being triggered, and/or more than 20 could be requested at any one time which means some alerts won't be able to have an IP Log created.
So IP Logging event actions should be limited to only those alerts where the additional data is manditory.
Also understand that IP Logging can have a negative impact on sensor performance. If you plan on using IP Logging often, then consider using a sensor rated for higher speeds than what you will be monitoring.