> Well, part of the problem is that, as remote-root exploits go, it ISN'T
> very serious. Relatively few people run named in the first place, and of
> those, relatively few of them enable fake-iquery (which is not all that
> useful anyway). But a larger percentage of Red Hat systems seem to have
> fake-iquery enabled, maybe it was by default in 4.x. (What about 5.0?)
I contend that all external root accesses are serious, because of how
easy it is for one cracker to scan huge numbers of hosts and nail them
all in an automated fashion. Even if any particular user isn't likely
to be at risk, a systematic attack on a given OS really damages that
OS's credibility. I'm trying to get more of my department to switch
from Sun to Linux, and that effort's taken a serious blow this week.
My understanding is that the named that was included in 5.0 (which I
am running) and perhaps earlier has the inverse query on by default
(it's a compile-time option as well as a config file option). One of
the install options for Red Hat is a caching named. This is a named
that doesn't serve any new names to anyone, but that records all the
names it gets and serves those to anyone who asks. That's all I was
running and I don't know what fraction of systems run this way. If
your nameserver is on a different subnet, caching is a good way to
never to see temporary net flakiness in name service.
--jh--
Joe Harrington
326 Space Sciences Building
Cornell University
Ithaca, NY 14853-6801
[EMAIL PROTECTED]
[EMAIL PROTECTED] (permanent)
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.