Help: BIND 8.2.2_P5 hangs on Red Hat 6.2

[Hank Leininger]

On 2000-10-22, patl at cag.lcs.mit.edu (Patrick J. LoPresti) wrote:

> As I said, the affected system is our loghost.  It does not *send*
> syslog messages to remote machines; it *receives* them.  So syslogd on
> this system does many reverse-DNS lookups, and those occasionally
> trigger the deadlock with named.  At least, this is what we suspect is
> happening (thanks again to Mark Andrews for his help).

This sounds plausible (do you have anything besides 127.0.0.1 listed in
this box's /etc/resolv.conf?).  If you haven't tried this already, try kill
-USR1'ing named next time it gets into this state -- it'll start logging
debug info, and you'll be able to see "yeah, it's blocking seconds at a
time trying to syslog, and answering queries a minute after they are
received," etc.  And/or strace -p <namedpid> or <syslogdpid>.

> If this analysis is correct, then even with the latest updates there
> remains a denial-of-service attack against Red Hat 6.2 named+syslogd
> when syslogd is started with the -r ("receive remote messages")
> option.  The easiest workaround is to configure named not to use
> syslog.

Yeah, but having named logs seperate from syslog logs *on your loghost*
seems a bit gross, no?  ;)

Other workarounds I can think of are: configure syslogd not to resolve
remotely logged packets.  Unfortunately this doesn't seem to be an option
in Linux's sysklogd :(  But it'd be easy to add and seems to me to make
sense; you could DIY and/or appeal to the maintainers (hm, or me, I'd take
a whack at it).  Or look at some of the "better syslog than syslog"
replacements out there to pick one that supports that.

Or, depending on how large your list of logging hosts is and/or how many
different "zones of authoritative control" they are in (read: if you can be
assured you'll know about it whenever a host starts logging to the
loghost), you can add entries for all of them in /etc/hosts (or
/var/chroot/named/etc/hosts if named's running chrooted).

You could go one step further and set up ipchains filters that block UDP
traffic by default, and allow for DNS, and allow UDP 514 (syslog)
specifically for each log-client IP listed in the hosts file.  This sounds
like a PITA (and it can be :) but there's times when it's worth it.  (In
reality the overhead may simply be, a script that dumps hostfile entries
from the reverse zone, and generates ipchains rules automatically from
same; then all you "must" achieve is to have PTR records for each logging
client.  This can be considered a feature.)

--
Hank Leininger <hlein at progressive-comp.com>