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'.
