Is it possible for CSIDS to log the entire packet when triggering an alarm? I know some context is put into the context field, but it is hard to use this to confirm an attack without a doubt. Having the whole packet would help. Thanks.
CSIDS does not currently have the ability to log the packet that generated the alarm.
The IP Log feature can be used to capture all packets to and from the source address after the alarm has fired, but does not log the actual packet or the one prior to the alarm firing.
Cisco is aware of this request from several users and is prioritizing it with the other enhancement requests we receive for future versions.
Note: For alarms based on a pattern within a TCP Session, the IPLog feature in conjunction with the context field of the alarm can be used in most cases to determine if the alarm was for an actual attack.
For those alarms based on packet headers, the IP Log will still work in many scenarios. The actual packet will not be logged, but the next packets may exhibit the same problem detected by the sensor.
If an attack is consistently from the same source, then the sensor can also be configured to log all packets to/from that source. Then when an alarm comes in, all of the packets to'from that source are available. This, however, should be used sparingly since it can have an impact on sensor performance.
When ulitmately implemented the logging of the actual packet generating the alarm may still not provided all of the information you need. For signatures that look at sessions, there may be several packets carrying the information that is needed to determine if an alarm should fire. For example, with a buffer overflow the attack will span multiple packets. The sensor with the new feature would log the last packet of the attack that caused the alarm to fire, and then the subsequent packets. It won't be able to log all of the packets that were used in the attack because this would require that all packets be kept in memory until an alarm fires. WIth sensor's monitoring 500Mbps of traffic, and an attack that may span a minute before the sensor can determine an attack is underway the sensor would have to maintain a possible 30 Gig of packets in active memory. So from a resource standpoint the sensor can't retro log packets prior to the alarm firing. The best that can be done is to log the last packet that finally triggered the alarm, and the packets after it.
To overcome this limitation some users have implemented a sniffer watching the same traffic. The sniffer logs all packets (or packets matching a particular filter) on the network directly onto the harddrive. Since little or no packet analysis is being done, and the packets are immediately being written to the harddrive rather than saved in memory, the sniffer is able to log the packets that the sensor won't. Some sniffers maintain a circular buffer of several Gig that automatically overwrites the oldest when the buffer is full. Some users have implemented their own scheduled scripts to emulate the circular buffer by removing the oldest packet logs on a scheduled basis.
Then when an attack comes, the user pulls all information from the packet logs about that connection.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...