On Fri, 19 Mar 2004, Alton Danks wrote:
> Hello,
>
> Would someone give these rules a run and see how much trouble they cause?
> There might be some obvious overlap with existing, better, rulesets. If you
> feel like pointing them out it would be great. One last thing, on the
[snip..]
> rawbody CTS_HREF /<a .{0,32}href[^=]/i
> describe CTS_HREF Href Obfuscation
> score CTS_HREF 1.0
Be careful of rules that are too general, real danger of FPs as well
as increased CPU load. (the greater the amount of ambiguity in the pattern
the more back-tracking involved for the pattern matching engine).
For example, your CTS_HREF rule will hit on:
<a href="http://www.href.com";>HREF Tools Corp. home page</a>
(or almost any other URL that happens to have the substring
'href' in the hostname or page name. ;)
Here's the rule that I wrote (probably for the exact same kind of
spam that inspired you to write your 'CTS_HREF' ;):
rawbody L_FAKE_HREF /\w\whref="?http:/i
describe L_FAKE_HREF Faked href to hide spammer URLs
score L_FAKE_HREF 2.1
Dave
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
