09-20-2007 08:47 AM - edited 03-10-2019 03:48 AM
The alarm is attached. Based on my feeble attempts to read the IP header included in the alarm, the Don't fragment bit is set and the frag offset is zero. Why is this signature firing?
09-26-2007 10:13 AM
It's not necessarily to do with fragmented packets, it depends on what signature actually fired. It will be one of the normalizer engine sigs, and the action on that signature will be "deny-connection-inline" meaning once the sig fires all subsequent packets on that connection are denied/dropped
09-26-2007 10:31 AM
not sure I follow you. we're not inline, we're in promiscuous mode. The signature that actually fired is in the heading of the posting...1225-0. Unless I'm reading it wrong, the trigger packet has the "do not fragment" bit set and has no fragment offset value. To the untrained eye, this appears to be a normal unfragmented packet.
09-26-2007 12:34 PM
This appears to be is a big scary bug. I didn't initially bother to valid the trigger packet source and destination IP address. I should have. The trigger packet has a destination address of 206.195.196.91 and NOT 192.168.10.10. The firewall logs show that there WAS a session between 75.211.49.149 and 206.195.196.91 during this time period. I don't know what to make of this other than at least once my IDS fired a completely and utterly mashed up mess of an alarm
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide