I have enabled the SPAM signature 3106 on my sensors. I have used the Epologue command to change the NumberOfRcptTo 10. I set the action to IPLog, TCP Reset, and Block. It shows NumberOfRcptTo 10 at the bottum of the packetd.conf file and I see the alert generated in Event Viewer. So i think the signature is working. But I sent an email to 13 people from outside my organization and the recipients still recieved the message.
You can look in the /usr/nr/var/iplog directory or the /usr/nr/var/iplog/new directory for hte IPLOG file that would have been generated. The IPLOG should be named with the ipaddress of the source of the alarm.
I recommend using the tool etheal to view the contents of the IPLOG to see what happened to the connection after the alarm fired. Ethereal can be downloaded from www.ethereal.com.
3) Did the TCP Reset get executed?
The only way to verify if the TCP Reset was actually executed is to sniff the network as the attack takes place. Since you are creating the attack yourself you can run the following command on the sensor as user root: "snoop -d spwr0 " to sniff the traffic between your machine and the email server. If you are using the IDS-4210 then change spwr0 to iprb0.
You chould see the connection and see Reset packets after the alarm fires.
Things to keep in mind:
a) If spanning off of a switch port then the switch may block these Reset packets from the sensor.
b) The Resets do not always work. They are the sensor's best guess at the connection sequence. Version 3.0 does a little better job, but it is still not guaranteed to work.
c) Some email clients will re-establish and complete the email even after having been Reset.
You can also look at the IPLOG to see what happened after the alarm fired to see if the connection was reset and restarted.
4) Was the connection Blocked?
To block the connection you would have had to setup the sensor to control the acls on a router between your machine and the email server. Check to see if the acls were created, and check to see if they actually do block the packets. The acls may be applied to interfaces which do not affect your traffic. Also there is a small time delay from when the alarm fires and the acls are updated. During this time delay the email could have been completed and sent. So only traffic after that may have been blocked.
Once again check to see if the connection continued after the alarm fired by checking the IPLOG file. If the connection continued then the router acl changes did not block the connection.
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 :