Paul Vixie wrote:
whoa. this is like deja vu all over again. when barb@CERT asked me to patch BIND gethostbyaddr() back in 1994 or so to disallow non-ascii host names in order to protect sendmail from a /var/spool/mqueue/qf* formatting vulnerability, i was fresh off the boat and did as i was asked. a dozen years later i find that that bug in sendmail is long gone, but the pain from BIND's "check-names" logic is still with us. i did the wrong thing and i should have said "just fix sendmail, i don't care how much easier it would be to patch libc, that's just wrong."
are we really going to stop malware by blackholing its domain names? if so then i've got some phone calls to make.
Okay, what I am about to suggest here is clearly going to be heretical, and I have to admit I thought about it before reading Paul's post... but I still want to put it out for thought. Clearly, the bad guys are manipulating DNS as a means to hide. Quoting Gadi from earlier: "Every day we see two types of fast-flux attacks: 1. Those that keep changing A records by using a very low TTL. 2. Those that keep changing NS records, pretty much the same." So, since they are manipulating DNS, how about trying to "fix" DNS as somewhat of a work-around here? After all, this is a DNS issue, and **MAYBE** a patch to BIND may be the easiest temporary work-around? What I would suggest is as follows: Add an option to BIND that: a) Returns a lookup failure if the TTL for the NS or A record is "too low" b) Caches the failure record for the server's "negative lookup" TTL time period to slow the rate of future lookups c) Clearly flags the forced failure in the query log to allow for the identification of potentially infected hosts and to help evaluate the effectiveness of this kludge There should probably be separate options for setting minimum acceptable NS and A TTLs. I would think that in most circumstances you would want to consider rejecting NS RRs with TTLs < 4hrs and A RRs with TTL < 1hr. If my bit-herding skills were a little more up to date, I might have even tried to write such a patch myself. I think we can all agree that this is a "BAD IDEA", but given the current circumstances, maybe this bad idea could be the lesser of several evils? Maybe we could get an "unofficial" patch from someone outside the ISC to allow this idea to be tried, thus avoiding ISC's having to forever support another bad idea that in reality didn't fix much? I would posit that if we don't try it, we would never know how effective it would be. Jon -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.