[Snort-devel] Re: [Snort-users] Has anybody checked this out?
roesch at ...48...
Wed Feb 28 00:38:01 EST 2001
This can't happen. All alert rules are processed before log rules, so
if there's an alert rule specified for an event, it *will* alert no
matter what order it appears in the rules file. This is by design.
Burak DAYIOGLU wrote:
> Martin Roesch wrote:
> > I'm not quite sure what you mean when you discuss "hiding attacks" from
> > Snort by flooding with malformed packets. Snort stops analyzing a
> > packet as soon as it hits on a rule match, there's no performance
> > penalty once an alert has been triggered, and there's no hiding traffic
> > (unless the sensor gets flooded and can't keep up with the traffic).
> I'm not talking about flooding or DOSing type of attacks to hide a more
> important attack. This discussion is totally non-related with the
> previous discussion regarding floody malformed packets; sorry for the
> Instead, I'm talking about hiding an attack carried out by utilizing the
> current stop-at-first-match behaviour of Snort. Consider such a case:
> a. an attacker constructs a packet malicious packet
> b. snort is configured such that for that particular packet in (a),
> two rules would be triggered (e.g. first one's action is log,
> second is alert)
> b. attacker sends packet
> c. snort picks up the packet and starts matching against the rule base
> d. When matching it against the rule base, the first rule (which is
> with the "log" action) is triggered
> d. A log entry is generated possibly with the whole copy of the packet
> but an alarm is not.
> However, at that very point, the attacker has carried out an attack
> (which is really serious) but hide it by showing it as a low-priority
> event to snort.
> It's a pity of me to not be able to materialize such a case but I am
> pretty sure there are plenty of ppl around to come up with some
> creative ideas.
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
roesch at ...48...
More information about the Snort-devel