One of my beefs with any IDS system is the inability to see the network environment that caused the signature to trigger. Context buffers help, IPLog helps after the fact, but as you all know the data right before the triggered is just as important.
So I was wonderin'..... Since each sensor comes with snoop and a big old hard drive, how about a process that runs snoop and logs everything on spwr0 to a file. Say 30 minutes worth.
This process would be implemented in some ring buffer fashion, so that at any time one of my analysts gets an alert they can pull up the latest file and analyse the last 30 minutes worth of network traffic.
The only question is, how to implement this ringbuffer idea properly.
I auppose you could use cron jobs to rotate a log file every 30 minutes to get the job done, but please be warned that running snoop / tcpdump on a sensor can dramatically effect the sensor's ability to function properly. The sensors were not designed to do this. Another alternative is run another system to sniff the traffic. The important thing is to make sure the time sources are sync'd on the sensor and the sniffer. A good (and cheap) solution for collecting log files is to use the client portion of the SHADOW IDS system available at
I caution against doing this on the sensor itself.
The capturing and logging of the packets is very cpu, memory, and harddrive intensive. And will severely affect sensor performance.
If you decide to implement this then you will need a sensor rated far above the amount of traffic you intend to monitor. For example if you have 70 Mbps of traffic then IDS-4230 with this amount of packet logging will not likely keep up. You would probably need at least an IDS-4250.
As Matt suggested, a more affordable solution would be to use a second machine for just the logging. You could get a fairly high powered pc for only a few thousand compared to the $25,000 for the IDS-4250.
I posed the same question earlier this year -- use the seperate PC. Buy large hard drives (ATA RAID is super cheap too) and spool an hour. It is VERY helpful to be able to see events on both sides of the trigger.
Exactly right. We've been using logging boxes like this alongside of the Cisco sensors for several years now. I don't know how you can truly "do" IDS without this kind of information. The boxes paid for themselves within weeks because of cutting down on investigative work (if you have the pcaps, no need to guess at what could have triggered the alert), and full 1500-byte packets are usually vital for legal reasons if an incident goes that far.
I would HIGHLY recommend installing a system that does long term packet logging (days rather than minutes).
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :