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.<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 -> $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,<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 -> $HOME_NET 1024 (msg:"Test Rule Static Port"; flowbits:isset,dce.bind.msdtc; content:"|00|"; 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->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.</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>