Testing Botnet

[Arthur Dent <sa...@troodos.demon.co.uk>]

Hello All,

I'm afraid that I might have wasted your time - Hence the change to the thread
Subject. 

I guess that what triggered my original question was the fact that I was
trying to check that everything was working following an OS upgrade. Looking
back through my spam corpus it seemed that I would get "Botnet Serverwords" in
the headers of probably about 2 out of three spam emails (it was however
scored at 0).

These stopped abruptly in October when I upgraded SA.

Only very rarely would I get a "BOTNET Relay might be a spambot or virusbot"
hit (and in fact I have only one remaining in my corpus).

Trying to test Botnet I have tied myself up in knots and only just now thought
of piping that mail trough with the -D switch set. When I do that it certainly
seems that Botnet is loading and running on the message (output below if
you're interested) but it doesn't hit.

Leaving aside the issue of why it hit before but doesn't now, is there any
recognised test (like GTube) for Botnet?

Is it possible that SA 3.2.3 no longer reports the zero scoring "ServerWords"
and that I simply haven't had a "Relay might be a spambot or virusbot"
event since the upgrade?

Forgive my ignorance, I really don't fully understand how Botnet works, but:

Might it be that my test email *was* a spambot when I originally received it,
but *no longer* is?

Any enlightenment gratefully received...

AD

[mark@mydomain tmp]$ spamassassin -D < testspam 2>&1 | grep -i botnet
[17484] dbg: config: read file /etc/mail/spamassassin/Botnet.cf
[17484] dbg: config: fixed relative path: /etc/mail/spamassassin/Botnet.pm
[17484] dbg: plugin: loading Mail::SpamAssassin::Plugin::Botnet from
/etc/mail/spamassassin/Botnet.pm
[17484] dbg: Botnet: version 0.8
[17484] dbg: plugin: Mail::SpamAssassin::Plugin::Botnet=HASH(0x97a0684)
implements 'parse_config', priority 0
[17484] dbg: Botnet: setting botnet_pass_auth to 0
[17484] dbg: Botnet: setting botnet_pass_trusted to public
[17484] dbg: Botnet: adding ^127\.0\.0\.1$ to botnet_skip_ip
[17484] dbg: Botnet: adding ^10\..*$ to botnet_skip_ip
[17484] dbg: Botnet: adding ^172\.1[6789]\..*$ to botnet_skip_ip
[17484] dbg: Botnet: adding ^172\.2[0-9]\..*$ to botnet_skip_ip
[17484] dbg: Botnet: adding ^172\.3[01]\..*$ to botnet_skip_ip
[17484] dbg: Botnet: adding ^192\.168\..*$ to botnet_skip_ip
[17484] dbg: Botnet: adding ^128\.223\.98\.16$ to botnet_pass_ip
[17484] dbg: Botnet: adding (\.|\A)amazon\.com$ to botnet_pass_domains
[17484] dbg: Botnet: adding (\.|\A)apple\.com$ to botnet_pass_domains
[17484] dbg: Botnet: adding (\.|\A)ebay\.com$ to botnet_pass_domains
[17484] dbg: Botnet: adding (\b|\d).*dsl.*(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)cable(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)catv(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)ddns(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)dhcp(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)dial(-?up)?(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)dip(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)docsis(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)dyn(amic)?(ip)?(\b|\d) to
botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)modem(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)ppp(oe)?(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)res(net|ident(ial)?)?(\b|\d) to
botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)bredband(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)client(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)fixed(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)ip(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)pool(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)static(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)user(\b|\d) to botnet_clientwords
[17484] dbg: Botnet: adding (\b|\d)e?mail(out)?(\b|\d) to botnet_serverwords
[17484] dbg: Botnet: adding (\b|\d)mta(\b|\d) to botnet_serverwords
[17484] dbg: Botnet: adding (\b|\d)mx(pool)?(\b|\d) to botnet_serverwords
[17484] dbg: Botnet: adding (\b|\d)relay(\b|\d) to botnet_serverwords
[17484] dbg: Botnet: adding (\b|\d)smtp(\b|\d) to botnet_serverwords
[17484] dbg: Botnet: adding (\b|\d)exch(ange)?(\b|\d) to botnet_serverwords
[17484] dbg: rules: ran header rule __BOTNET_NOTRUST ======> got hit:
"negative match"
[17484] dbg: Botnet: starting
[17484] dbg: Botnet: no trusted relays
[17484] dbg: Botnet: get_relay didn't find RDNS
[17484] dbg: Botnet: IP is '194.217.242.223'
[17484] dbg: Botnet: RDNS is 'lon1-hub-3.mail.demon.net'
[17484] dbg: Botnet: HELO is ''
[17484] dbg: Botnet: sender 'MAILER-DAEMON@mydomain.org.uk'
[17484] dbg: Botnet: miss (none)
[17484] dbg: check:
subtests=__AUTO_GEN_AS,__BOTNET_NOTRUST,__BOUNCE_AUTO_GENERATED,__BOUNCE_CTYPE,__BOUNCE_RPATH_MD,__CT,__CTYPE_HAS_BOUNDARY,__DOS_BODY_SUN,__DOS_HAS_ANY_URI,__DOS_RCVD_SUN,__DOS_REF_TODAY,__DOS_RELAYED_EXT,__HAS_ANY_EMAIL,__HAS_ANY_URI,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAVE_BOUNCE_RELAYS,__LAST_UNTRUSTED_RELAY_NO_AUTH,__LOCAL_PP_NONPPURL,__MIME_VERSION,__MISSING_REF,__MSGID_OK_DIGITS,__MSOE_MID_WRONG_CASE,__NONEMPTY_BODY,__RCVD_IN_DNSWL,__RDNS_NONE,__SANE_MSGID,__SARE_BOUNDARY_D12,__SARE_HEAD_HDR_RMDA,__TOCC_EXISTS,__TVD_BODY
[mark@mydomain tmp]$

Disabling eval rules (was: Re: Testing Botnet)

[Karsten Bräckelmann <gu...@rudersport.de>]

On Sat, 2008-01-12 at 12:23 -0800, Robert - elists wrote:

> > Sounds like you've been hit by bug 5519 [1] before the upgrade in Oct.
> > Setting rules scores to 0 did *not* prevent these tests from being
> > evaluated for SA 3.2.x before 3.2.3.
> > 
> > Fixed since 3.2.3.  Plugin eval rules with 0 scores are meant no not be
> > evaluated, and of course to not show up in the report.

> Interesting, does this mean that we should be changing scores we care about
> and want to see eval'd in the reports to .01 or something similar?
> 
> Any other implications in the bug and current or future fix methods?

AFAIK, nope. That should be all.  However...


I noticed that even my SA 3.2.4 still evaluates my URICountry plugin
rules, which are set to a score of 0.0 [1]. Which actually should *not*
happen since 3.2.3.

Anyone got a guess why?  Devs?

  guenther


[1] originally set up for exactly this testing purpose, btw

-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

RE: Testing Botnet

[Robert - elists <li...@abbacomm.net>]

> 
> Sounds like you've been hit by bug 5519 [1] before the upgrade in Oct.
> Setting rules scores to 0 did *not* prevent these tests from being
> evaluated for SA 3.2.x before 3.2.3.
> 
> Fixed since 3.2.3.  Plugin eval rules with 0 scores are meant no not be
> evaluated, and of course to not show up in the report.
> 
>   karsten
> 

Karsten

Interesting, does this mean that we should be changing scores we care about
and want to see eval'd in the reports to .01 or something similar?

Any other implications in the bug and current or future fix methods?

 - rh

Re: Testing Botnet

[Karsten Bräckelmann <gu...@rudersport.de>]

On Sat, 2008-01-12 at 18:03 +0000, Arthur Dent wrote:
> Hello All,
> 
> I'm afraid that I might have wasted your time - Hence the change to the thread
> Subject. 
> 
> I guess that what triggered my original question was the fact that I was
> trying to check that everything was working following an OS upgrade. Looking
> back through my spam corpus it seemed that I would get "Botnet Serverwords" in
> the headers of probably about 2 out of three spam emails (it was however
> scored at 0).
> 
> These stopped abruptly in October when I upgraded SA.

Sounds like you've been hit by bug 5519 [1] before the upgrade in Oct.
Setting rules scores to 0 did *not* prevent these tests from being
evaluated for SA 3.2.x before 3.2.3.

Fixed since 3.2.3.  Plugin eval rules with 0 scores are meant no not be
evaluated, and of course to not show up in the report.

  karsten


[1] Zeroing a score does not disable plugin eval rules
    http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5519

-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}