Once the sensor detects a signature it creates the alarm and then executes the associated actions for that signature.
So shunning takes place after the signature has been detected by packetd and an alarm is created.
Also the IP Logging takes place after the signature has been detected by packetd and an alarm is created.
So for IP Logging the packet (or packets) that caused the triggering of the signature are not included in the IP Log, instead only the packets seen after the triggering of the signature are copied to the IP Log files in /usr/nr/var/iplog directory.
In the case where both Shun and IP Log are used with the same signature then the shun will reconfigure the router to block the traffic. So if the sensor is sniffing behind the router that is blocking the traffic then IP Log will only contain the few packets after the signature fired and before the shun took place.
NOTE: There is already an enhancement request that the packets which triggered the signature be included in the IP Log file. This enhancement request is being evaluated by our management and development teams.
For now the data that can be used to evaluate why a signature fired is the Context Data. The Context Data is viewable in either CSPM or the OV interface of the Unix Director. Each time that packets come in for a specific connection the data they contain is loaded into a context buffer. For signatures that look at the data of the packets such as the majority of the web signatures, then it is this data in the context buffer that is searched for the signature. If the signature is found in that buffer then the data in the context buffer is inlcuded as part of the alarm when it is sent to the management station. NOTE: For alarms whose signatures are based on the packet headers the context buffer is not searched so it is not included with those alarms when sent to the management station.
If the same alarm keeps coming from the same source address then the user could also try the following.
1) Configure a permanent IP Logging Address using the token RecordOfLogAddress in packetd.conf.
Normally IP Logging is only done when a specific signature fires and then it logs the packets only for the time designated by the token MinutesOfAutoLog. But by using the RecordOfLogAddress the sensor will from that point forward capture all packets to and from the source without any time limits.
2) Wait for the alarm to fire for that source.
3) Write down the source address and port, and destination address and port for the connection causing the alarm.
4) Now use ethereal or the transcipt program on the Unix Director to analyze the IP Log file that was being created.
5) Remove the RecordOfLogAddress token from packetd.conf and restart the sensor.
NOTE: IP Logging can be resource intensive for the sensor, and so IP Logging should be kept to a minimum necessary for the analysis necessary. So be sure to remove the RecordOfLog Address token when you are done so that the sensor doesn't waste CPU cycles logging large amounts of packets you may never look into.
As for the Pop Buffer over flow (Sig 3550) it will fire on lines with over 512 bytes sent to port 110.
