Re: Those Re: good obfupills spams (uridnsbl's, A records vs NS records)

2006-04-28 Thread Matt Kettler
List Mail User wrote:

 
   These few rules can help a lot (potentially with some possible FPs
 though).  And as always, train your BAYES with the ones that get through
 and enable the digest tests (i.e. DCC, Pyzor and Razor).
 
 uridnsblURI_COMPLETEWHOIS   
 combined-HIB.dnsiplists.completewhois.com.  A
 bodyURI_COMPLETEWHOIS   
 eval:check_uridnsbl('URI_COMPLETEWHOIS')
 describeURI_COMPLETEWHOIS   URI in 
 combined-HIB.dnsiplists.completewhois.com
 tflags  URI_COMPLETEWHOIS   net 
 score   URI_COMPLETEWHOIS   1.25

snip
 
   These rules help to catch brand new domains at the same IP as
 previous spam domains (i.e. they are IP based BLs). 

Neat stuff Paul.. I'll have to try it out.


That said, technically, doesn't this really look up the IP address by fetching
the NS record, not the A record of the URI? (this would catch domains hosted at
the same nameserver, not domains hosted at the same server IP address)

Or has SA changed and it looks up both NS and A for uridnsbl?

I know previously there was a strong argument against looking up the A record,
as it provided an opportunity for spammers to poison email with extra URIs that
nobody would normally click on or lookup. These poison URIs could be used to
trigger DNS attacks, or simply generate slow responses to force a timeout.

NS records on the other hand are generally not handled by the spammer's own DNS
servers, but are returned by the TLD's servers.

ie: the NS record for evi-inc.com is stored on my authoritative DNS server, but
it's only there for completeness. Nobody normally queries it from there except
my own server. Most folks find out the NS list from the servers for .com (ie:
a.gtld-servers.net). This makes it impractical to perform poison URIs if SA is
only looking up NS records.









Re: Those Re: good obfupills spams (uridnsbl's, A records vs NS records)

2006-04-28 Thread List Mail User
Neat stuff Paul.. I'll have to try it out.


That said, technically, doesn't this really look up the IP address by fetching
the NS record, not the A record of the URI? (this would catch domains hosted at
the same nameserver, not domains hosted at the same server IP address)

Or has SA changed and it looks up both NS and A for uridnsbl?

I know previously there was a strong argument against looking up the A record,
as it provided an opportunity for spammers to poison email with extra URIs that
nobody would normally click on or lookup. These poison URIs could be used to
trigger DNS attacks, or simply generate slow responses to force a timeout.

NS records on the other hand are generally not handled by the spammer's own DNS
servers, but are returned by the TLD's servers.

ie: the NS record for evi-inc.com is stored on my authoritative DNS server, but
it's only there for completeness. Nobody normally queries it from there except
my own server. Most folks find out the NS list from the servers for .com (ie:
a.gtld-servers.net). This makes it impractical to perform poison URIs if SA is
only looking up NS records.


Matt,

While I'd like to see two classes of rules, and both types of BLs
used for both types of lookup (preferably with different scores - since
my testing shows very different FP and FN rates for 'A' and 'NS' checks),
you are completely correct:  IP based BLs are only used for the 'NS' checks
and RHS based BLs are only used for targeted domain checks (and not for the
domain of the URI's NSs).  Currently nothing is used to directly check the
IP of the spam site (i.e. the 'A' RR), but since in many cases this happens
to be the same as the NS' IP, the IP based BLs often are checking it (though
almost by accident).

I personally think that poisoning spam with extra URIs is already
seen quite a bit, and the issue of DNS timeouts is almost a non-issue, since
you would be no worse off than before.  Already we see stock pumpdump and
419 spams with large amounts of poison URIs in them.  Ultimately the spammer
wants as short a message as he can get by with to maximize the use of his
own bandwidth (or the stolen bandwidth he has access to).

What makes these test much more efficient than you might expect is
that many very-large scale spammers (think ROKSO top-ten) tend to use the
same hosts/IPs for both the web hosting and the DNS server.  Also they tend
to reuse IPs so that last week's spam web server is this week's spam DNS
server.  This means that hosts that hit SORBS spam-traps are often name
servers for current spam runs using brand new domain names that haven't
made SURBL or URIBL lists yet (or sometimes, if you have the misfortune of
being at the start of a run, haven't even hit the digests yet).

I find (after already significant MTA filtering) that these few
rules hit about 10% to 25% of the spam I get.  The SORBS spam list alone
hits almost 25% of spam, but also hits about .85% of ham (but much of that
is email that many people would consider spam),  The completewhois list hits
about 12% of spam, but again, ~.7% of ham.  The meta rules hit slightly more
than the product of the hit ratios of the individual rules (i.e. including
the SBL) for spam (except the completewhois/SBL meta which hits 92% of the
original completewhois hits - i.e. mostly Chinese and Korean IPs, but some
from all parts of the world), and have a no ham hits over the past two or
three months (and only one or two ever);  This implies that they are indeed
independent, with different FP sources and heavily biased toward spam to
begin with.  They do disproportionally catch certain spammers, so they can
be though of as similar to the SARE Specific rule set.  In particular they
work extremely well against certain classes of pill and mortgage spam.

Paul Shupak
[EMAIL PROTECTED]