Clunk Werclick wrote: > On Thu, 2009-09-03 at 05:23 -0400, Matt Kettler wrote: > >> Clunk Werclick wrote: >> >>> Howdie; >>> >>> I'm starting to see plenty of these and they are new to us: >>> >>> zgrep "address not listed" /var/log/mail.info >>> Sep 3 05:26:59 ....: warning: 222.252.239.56: address not listed for >>> hostname localhost >>> dig -x 222.252.239.56 >>> >>> ... >>> ;; QUESTION SECTION: >>> ;56.239.252.222.in-addr.arpa. IN PTR >>> >>> ;; ANSWER SECTION: >>> 56.239.252.222.in-addr.arpa. 83651 IN PTR localhost. >>> ... >>> >>> Taking to one side the various RBL's which are catching these, and not >>> going the whole 'PTR must match' route - would it be practical to craft >>> a 10 point rule based on PTR = localhost? Is it even possible to build a >>> rule based upon DNS returns? >>> >>> Forgive the stupidity of the question, but I'm not sure how to, or even >>> if it can be implemented? >>> >> Not without writing a plugin. Although if your MTA inserts a "may be >> forged" note into the Received: headers, SA will pick up on this. >> >> Generally speaking, SA does not perform A record lookups of anything >> that could be spammer-provided, neither hosts in URLs nor Received: >> hosts. Doing so posses a potential security risk. (NS record queries are >> performed, but not A). >> >> Attack vectors include: >> >> 1) malicious insertion of hosts that are slow-to-resolve, forcing a DNS >> timeout, thus slowing down mail processing. A small flood of such >> messages (each with different hostnames) could readily occupy all your >> spamd children. Spamd does not have sufficient cross child co-ordination >> to implement countermeasures, and anyone using the API or "spamassassin" >> script would have to roll their own. >> >> 2) there is the potential to abuse chosen queries to facilitate DNS >> cache poisoning attacks, on servers that are vulnerable. >> > > Thank you Matt. That is a fine quality of answer and makes total sense. > I had never thought to consider this attack vector. On an SA install > running hundreds of thousands of messages I could see a significant > issue if DNS returns ran much past 300ms or so. I am guessing (and I > have not at all examined the code, nor shall I pretend that I would > understand it) that there is some kind of sanity check for DNS timeout > there someplace? Again, potentially a stupid question - but I'm curious > as to how we would say 'that query has taken too long, I'm out of > here'. > AFAIK, all the DNS lookups for a message are subject to the rbl_timeout code.
See to conf docs: http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html
