Re: Average delay per packet observation

[Joshua Kinard via Snort-devel <snort-devel () lists snort org>]

On 07/07/2017 09:57, Navdeep Uniyal wrote:
> Hi Steven,
>
> Below are the rules I am using in my snort.conf:
>
> alert udp any any -> any any (msg:"GENERAL UDP ALERT!!! UDP Packet Received";sid:278;rev:3;)
> alert udp 172.17.0.3 any -> any any (msg:"SENDER IP ALERT!!! IP Address found and now printing the 
> same";sid:279;rev:3)
> alert udp any any -> any any (msg:"TIME TO LIVE ALERT!!! TTL- TTL<=60.. FOUND!!!";ttl:<=60;sid:280;rev:3;)
> alert udp any any -> 10.10.1.101 any (msg:"RECEIVER IP ALERT!!!! Receiver IP Address Found...";sid:281;rev:3;)
> alert udp any any -> any 8999 (msg:"PORT ALERT!!!! UDP packets sent to PORT 8999";sid:282;rev:3;)
>
> These are the set of 5 rules which I am repeating (with different sid) to create 10,20,40 and 80 rules.
> As I understood from your explanation, the matching algorithms will work only for 5 times in all the cases ( please 
> correct me if I am wrong).
>
> Now since I am logging the alerts on the screen, I am getting alerts for all 10,20,40 or 80 rules in each case. What 
> could be the potential reason of getting the delay in a factor of 10^-4 in case of 80 rules but for 40,20 and 10, it 
> is for a factor of 10^-8.
>
>
>
> Best Regards,
> Navdeep

You are seeing this effect because Snort is, first and foremost, a
wickedly-fast "grep" for network packets.  It is *heavily* optimized for
matching strings in packet payload.  It is utterly abysmal in matching IP
addresses in the network layer of the packet (e.g., Snort is not a firewall).

When given a content match in a rule, all incoming packets are matched against
a selected "fast-pattern" match to preselect which packets ultimately will
enter the "detection engine".  The fast-pattern matcher is case-insensitive and
does not care where a string is located within a packet.  It only cares whether
the string exists or does not exist.  Case-sensitivity and specific location
are dealt with in the detection engine (as are other rule keywords).

When not given a content match in a rule, Snort will consider that rule
applicable for all packets, and that is why you are seeing the stated delays.
The more contentless rules you stack on top, the slower Snort's detection will
get, and, in excessive cases, Snort will simply start dropping packets on the
floor without even evaluating them.

If you really need to use contentless rules bound to specific IP addresses or
ranges, along with protocol-specific field checks, you might want to look at
the Suricata project instead, which has some differences to Snort, one of which
enables the use of such rules with its evaluation engine.

You also want to look at the large comment block at the top of the src/pcrm.c
file in Snort's source code (2.9.x), which gives some more detailed information
about Snort's approach to rules and packet processing.  IMHO, that should be in
the manual, but at least it's somewhere.

-- 
Joshua Kinard
Gentoo/MIPS
kumba () gentoo org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!