fygrave at ...1...
Fri Sep 22 10:54:22 EDT 2000
~ :I've been running it over here without any stability issues.
~ :However, one problem I see with the preprocessor is that on monitored
~ :ports one can get two alerts on the same attack signature. The reason is
~ :that if the attack is not a stealth attack (i.e. no one has broken the
~ :attack up into multiple tcp packets) the original packet itself generates
~ :an alert. Then, the dummy packet based on the reconstructed stream will
~ :get sent later on and also generate an alert.
~ :There are a few ways I see around this. One would be to have the stream
~ :preprocessor ignore larger packets.
Hmm.. If I understand your concerns correctly, it doesn't seem that it
would solve the problem in all cases. As far as I understand a tcp packet
would be passed to detection engine twice, first time when it is captured
straight off the wire, and the second time when it becomes a part of a
dummy packet (tcp reassembled stream). What ideally should be here is some
sort of feedback from detection engine to tcp reassembly engine to mark
currently reassembled packet `triggered alert X'. Later if the packet
matches certain signature, dection engine should verify whether this
packet (a part of it) has already `triggered alert X'... we should think
carefully though how to implement it properly, since we still would like
to see core snort system being independant from preprocessors, maybe
bring up some sort of detection preprocessors thing or place the thing
into alert/log engine?
More information about the Snort-devel