[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snort-devel
Subject:    [Snort-devel] Port Range Rule Performance
From:       Joel Ebrahimi <joel.ebrahimi () gmail ! com>
Date:       2009-05-28 19:49:38
Message-ID: 46ee7b1c0905281249u5ec54a29pce51bef3e70b809b () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I was doing some snort performance tests recently. I was using benign
traffic (all 0's) on an off port and did not expect snort to have to do much
work. I noticed snort was actually working really hard. I enabled rule
performance monitoring and I noticed there were 20 or so rules that were
 doing checks on all the packets and were using up processor time. It turns
out all of the rules were port range rules. Most of which had a range of
port 1024 and up or 1024 to 2048, so I picked both my src and dest port for
my testing to be 1023. After running the same test again, I noticed that the
same results even though the port fell outside of the range.
I then decided to take 2 existing snort rules and modify them a little to
run some tests. Here are the rules I used:

alert tcp $EXTERNAL_NET any -> $HOME_NET 1024:2048 (msg:"Test Rule Port
Range"; flowbits:isset,dce.bind.msdtc; content:"|00|";
reference:bugtraq,17905; reference:cve,2006-0034; reference:url,
www.microsoft.com/technet/security/bulletin/MS06-018.mspx;
classtype:attempted-admin; sid:2006462; rev:4;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 1024 (msg:"Test Rule Static Port";
flowbits:isset,dce.bind.msdtc; content:"|00|"; reference:bugtraq,17905;
reference:cve,2006-0034; reference:url,
www.microsoft.com/technet/security/bulletin/MS06-018.mspx;
classtype:attempted-admin; sid:2006463; rev:4;)

You would think that neither of these rules would do any work on port 1023
traffic. Which is the case for the static port rule but as noted above the
port range rule still processes the rule.

Further analysis showed that the port range rule increments the generic
counter p->prmGeneric->pgCount. Then when you enter the
function prmFindRuleGroup the check between these 2 rules differ when if(
!stat &&  ((p->prmGeneric != NULL) && (p->prmGeneric->pgCount > 0)) ) is
evaluated and the different return value impacts the path for further
analysis.

If there was a way to remove port ranged rules from doing further analysis
when the port is outside of the range that can help with performance.

Im not sure if any of that information will help in actually preventing port
ranged rules from not actually doing analysis, just thought Id point out
what I noticed in case it helps.

// Joel

[Attachment #5 (text/html)]

I was doing some snort performance tests recently. I was using benign traffic (all \
0&#39;s) on an off port and did not expect snort to have to do much work. I noticed \
snort was actually working really hard. I enabled rule performance monitoring and I \
noticed there were 20 or so rules that were  doing checks on all the packets and were \
using up processor time. It turns out all of the rules were port range rules. Most of \
which had a range of port 1024 and up or 1024 to 2048, so I picked both my src and \
dest port for my testing to be 1023. After running the same test again, I noticed \
that the same results even though the port fell outside of the range.<div> \
<br></div><div>I then decided to take 2 existing snort rules and modify them a little \
to run some tests. Here are the rules I used:</div><div><br></div><div><div>alert tcp \
$EXTERNAL_NET any -&gt; $HOME_NET 1024:2048 (msg:&quot;Test Rule Port Range&quot;; \
flowbits:isset,dce.bind.msdtc; content:&quot;|00|&quot;; reference:bugtraq,17905; \
reference:cve,2006-0034; reference:url,<a \
href="http://www.microsoft.com/technet/security/bulletin/MS06-018.mspx">www.microsoft.com/technet/security/bulletin/MS06-018.mspx</a>; \
classtype:attempted-admin; sid:2006462; rev:4;)</div> <div>alert tcp $EXTERNAL_NET \
any -&gt; $HOME_NET 1024 (msg:&quot;Test Rule Static Port&quot;; \
flowbits:isset,dce.bind.msdtc; content:&quot;|00|&quot;; reference:bugtraq,17905; \
reference:cve,2006-0034; reference:url,<a \
href="http://www.microsoft.com/technet/security/bulletin/MS06-018.mspx">www.microsoft.com/technet/security/bulletin/MS06-018.mspx</a>; \
classtype:attempted-admin; sid:2006463; rev:4;)</div> <div><br></div><div>You would \
think that neither of these rules would do any work on port 1023 traffic. Which is \
the case for the static port rule but as noted above the port range rule still \
processes the rule.</div><div> <br></div><div>Further analysis showed that the port \
range rule increments the generic counter p-&gt;prmGeneric-&gt;pgCount. Then when you \
enter the function prmFindRuleGroup the check between these 2 rules differ when if( \
!stat &amp;&amp;  ((p-&gt;prmGeneric != NULL) &amp;&amp; \
(p-&gt;prmGeneric-&gt;pgCount &gt; 0)) ) is evaluated and the different return value \
impacts the path for further analysis.</div> <div><br></div><div>If there was a way \
to remove port ranged rules from doing further analysis when the port is outside of \
the range that can help with performance.</div><div><br></div><div>Im not sure if any \
of that information will help in actually preventing port ranged rules from not \
actually doing analysis, just thought Id point out what I noticed in case it helps. \
</div> <div><br></div><div>// Joel </div></div>



------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 

_______________________________________________
Snort-devel mailing list
Snort-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic