Re: Average delay per packet observation

[Navdeep Uniyal <Navdeep.Uniyal () neclab eu>]

Hi Steven,

Thank you for your reply. I have tried using gprof with snort.
Edited src/Makefile with : "CFLAGS = -g -O2 -DSF_VISIBILITY -fvisibility=hidden -Wall -pg"

But there is no gmon.out file is getting created after executing snort. Could you please share if you have any 
experience with profiling snort.


Best Regards,
Navdeep

From: Steven Sturges [mailto:ststurge () cisco com]
Sent: Freitag, 7. Juli 2017 16:24
To: Navdeep Uniyal; snort-devel () lists snort org
Cc: Sachin Sharma
Subject: Re: [Snort-devel] Average delay per packet observation

The only difference between those is the IP addresses/ports, and one with TTL.
5 different copies of sid 278 will be evaluated at the same time.  Adding sid 279
on top of that, the only difference in checking is the source IP, which can evaluate
quickly.  Similar for the destination IP and port rules.  The one with TTL has a single
rule option check, once that check is made, the similar copies of SID 280 are not
adding additional evaluation time beyond the other 4 rules.

As the number of alerts getting generated for each packet likely goes up, you could
be simply measuring an I/O impact and/or a queuing.  By default, Snort will queue 8 of
alerts and only log 3 - so additional matches need to get checked for priority and
higher priority alerts, based on the prioritization order as defined or the default -- are
kept at the front of the queue.

This sounds like a research project and I'd recommend you look at the Snort code itself,
use a profiling tool, something like vtune, to determine how your rules are impacting
your observed "delay factor", relative to whatever you are using to measure that.
On 7/7/17 9:57 AM, 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

From: Steven Sturges [mailto:ststurge () cisco com]
Sent: Freitag, 7. Juli 2017 15:47
To: Navdeep Uniyal; snort-devel () lists snort org<mailto:snort-devel () lists snort org>
Subject: Re: [Snort-devel] Average delay per packet observation

The matching algorithms in Snort do not repeat the work when the rule options are the same.
And further, as soon as one of the options does not match, evaluation of that entire group of
rules is halted.

As I noted, it depends on the makeup of the individual rules themselves.  If the rules have
'content' options, as is recommended, and that pattern is not present in the traffic being tested,
there is no additional evaluation on the rules at all.  For example, even with 10000 rules where
the pattern from the content option is not present in the traffic, you would get roughly the same
performance as if you had only 10 of those rules.
On 7/7/17 4:52 AM, Navdeep Uniyal wrote:
Thank you for your reply.

In my case I am using a set of 5 rules repeated over(with different sid). So approximately each set should take the 
same amount of time relatively.
Example: 80 rules have (16*5) rules
                    40 rules have (8*5) rules
                    20 rules have (4*5) rules
                    10 rules have (2*5) rules

By this way, I assume the delay should get halved in each case from 80 to 40. But this is not happening as we can see 
from the results. Could you please help me in getting the explanation.


Best Regards,
Navdeep

From: Steven Sturges [mailto:ststurge () cisco com]
Sent: Mittwoch, 5. Juli 2017 13:43
To: Navdeep Uniyal; snort-devel () lists snort org<mailto:snort-devel () lists snort org>
Subject: Re: [Snort-devel] Average delay per packet observation


Rules are not processed sequentially.  Your expectations should depend on the nature of the

individual rules themselves.
On 7/4/17 10:16 AM, Navdeep Uniyal wrote:
Hello everyone,

I got some interesting results running snort (inline) for experiment with 80, 40, 20, 10 number of rules:
All rules are matching all the incoming UDP packets. Below are the average delay per packet I found in the 4 
experiments:

80 rules:              Average delay:  0.000680666813409 seconds
40 rules:              Average delay:  2.06440535385e-08 seconds
20 rules:              Average delay:  1.6644513569e-08   seconds
10 rules:              Average delay:  1.43723338507e-08 seconds

These results are quite confusing as I expect, on decreasing from 80 to 40 rules the average delay should be 
approximately halved. But I can't see such behavior here.

What could be the possible reason, if someone could explain.



Best Regards,
Navdeep







_______________________________________________

Snort-devel mailing list

Snort-devel () lists snort org<mailto: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!



_______________________________________________
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!