[Snort-devel] Average delay per packet observation
kumba at gentoo.org
Fri Jul 7 20:17:13 EDT 2017
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,
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.
kumba at gentoo.org
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
More information about the Snort-devel