Paul Vixie wrote:
whoa. this is like deja vu all over again. when [EMAIL PROTECTED] 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.
