On 3/29/2004 at 1:31 PM, "Justin Mason" <[EMAIL PROTECTED]> wrote:
> Tony Finch writes: >> On Mon, 29 Mar 2004, Jeff Chan wrote: >> > >> > So a technique to defeat the randomizers greater count is to look >> > at the higher levels of the domain, under which SURBL will always >> > count the randomized children of the "bad" parent. In this case >> > the URI diversity created through randomization hurts the spammer >> > by increasing the number of unique reports and increasing the >> > report count of their parent domain, making them more likely to >> > be added to SURBL. (Dooh, this paragraph is redundant...) >> >> Another approach is to blacklist nameservers that host spamvertized >> domains. If an email address or a URI uses a domain name whose nameservers >> are blacklisted (e.g. the SBL has appropriate listing criteria), or if the >> reverse DNS is hosted on blacklisted nameservers, these may be grounds for >> increasing the score. >> >> I don't know if SA does this check yet. > Yep, it does -- that's what the URIBL plugin does currently. sorry, I still haven't been able to test the -current version, but it was my understanding based on the discussion under [Bug 1375] that URIBL checks only check the RECURSIVELY RESOLVED 'A' records of the host part of a URI against DNSBLs. Justin: could you write a 5-liner saying what the final version of the module does, and in what order? I had previously thought this up as a defense against Ralsky's new randomized URLs like: http://[a-z]{14}.hfgr33.us : 1 - do non-recursive resolution of NS records for the second-level domain ONLY (I have a list of third-level delegations for various country TLD's, too, if required, but I have yet to see any spamvertized URLs in 3rd-level delegation domains), to avoid triggering their 'web bug' by way of them loging+tracking DNS lookups. This is a very fast query, always and only going to nameservers of TLDs, which will (hopefully) never be under the control of spammers playing DoS games. 2 - If we don't do this, they can easily tell what recipient MX hosts use this functionality, and singling these specific ones out with messages crafted to DoS this scheme in the future. This is especially important as long as these URIBL method(s) are not widely adopted - and I am not exclusively talking about SA here. 3 - do DNSBL lookups on all such nameserver IPs - if there's more than say: 4, pick N random ones from the list, where N = 4 + ((number_of_NS_hosts - 4) / 2 ) (e.g.: only every second one beyond the magic number of 4). - if you get DNSBL hits for 2 or more of the nameservers, abort all further lookups and return a match on the rule. 4 - when all nameserver IP's are "clear" of DNSBL hits, proceed to query them for A records for the hostname part of the URIs (or the IP numbers in numeric URLs, in which case you never went through steps 1-3), and do the DNSBL queries against them. There is plenty of evidence that major numbers of spamvertized domains/websites are using (*) SBL-listed nameservers and networks: stop worrying about FP's for innocent domains hosted on these nameservers: it will become impossible for providers to run nameservers that are SBL-listed, and be ignorant about it. If they were quick to terminate spamsites pointing to their NS's, they'd have never landed in the SBL in the first place. (*) listing policies of other DNSBLs may have substantially different results when used as URiBL query targets. The only thing I am unsure how to do with the above is: how to communicate that a rule match happened based on NS DNSBL hits, or based on DNSBL hits for A records for the host(s)? bye,Kai
