[Snort-devel] Re: [Snort-users] Has anybody checked this out?

Burak DAYIOGLU dayioglu at ...287...
Tue Feb 27 06:51:44 EST 2001

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.


More information about the Snort-devel mailing list