Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
You may experience some slow load times, errors, and slight inconsistencies. We ask for your patience as we finalize the launch. Thank you.

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Cisco Employee

Packet that triggered a "dropped" intrusion event reached a target host

Some packets from exploit attempts reach target hosts, although the intrusion events for those attempts show the related packets as dropped.

  • Event Analysis
Everyone's tags (1)
1 REPLY
Cisco Employee

The intrusion policies of

An intrusion policy of a FireSIGHT System runs in post-ACK mode by default. This means that data in reassembled streams (such as HTTP streams) are not matched against rules until an ACK for the data is received from the server. The server has already seen an HTTP request before the system alerts on it. The rest of the session will be blocked, but the malicious GET has already been processed.

 

To modify this behavior, the Inline Normalization feature needs to be enabled on the intrusion policy, and the options Normalize TCP and Normalize TCP Payload need to be turned on. Please read the following document to learn more about the Post-Acknowledgement and Pre-Acknowledgement Inspection by Inline Normalization preprocessor.

 

http://www.cisco.com/c/en/us/support/docs/security/firesight-management-center/117927-technote-firesight-00.html

 

In addition, if you are using a load balancer as a front end to your servers, your load balancer may be just looking at the first packet of a request and logging it based on that only. However, since Snort uses Protocol Aware Flushing (PAF), it does not alert or drop until it sees all of the packets of an HTTP request. If the load balancer is seeing only the first packet of a multi-packet request of which Snort has not dropped anything because the subsequent packets never made it to Snort, it may log the request inaccurately. Eventually, the sessions will get pruned because they have not seen data, and at that time the event will trigger because Snort will flush the rest of the stream. The event that gets generated will have the timestamp of the original data, not the time that Snort actually generated the event.

233
Views
0
Helpful
1
Replies