Re: BIND problem
Hi.
On Mon, 22 Feb 2016 20:44:23 -0700
Glenn English <ghe@srv.slsware.net> wrote:
>
> > On Feb 22, 2016, at 3:58 PM, Reco <recoverym4n@gmail.com> wrote:
> >
> > First one is 'ls -ald /var/cache'.
>
> root@log:~# ls -ald /var/cache
> drwxr-xr-x 14 root root 4096 Oct 12 2013 /var/cache
>
> > Second one is 'sudo -u touch /var/cache/bind/slaves/1'.
>
> sudo: unknown user: touch
> sudo: unable to initialize policy plugin
>
> (Should there have been a "bind" after the '-u'? I just tried that, and it returns an empty line.)
Yup, my mistake. But su got it.
>
> > 'su -l bind -c "touch /var/cache/bind/slaves/1"' should do it too since
> > you have an interactive login shell for bind.
>
> That one replies with an empty line. BIND's shell is still BASH (I thought I'd deleted that long ago).
>
> If I do 'su -l bind -c "touch /var/cache/bind/slaves/1" ; echo $?', it prints '0'.
>
> > Third one (hey, you never know) is 'ls -ald /'.
>
> drwxr-xr-x 25 root root 4096 Jun 6 2014 /
OK. That shows us two things:
1) Bind user is definitely able to create arbitrary files
in /var/cache/bind/slaves/.
2) Hence either zone files are dumped with, say, nobody privileges. Or
some other user.
Further investigation would require unhealthy amounts of strace, but ...
> ...
>
> Wait a minute. I just took a look at today's DNS log with 'cat /var/log/daemon | egrep permission' and I see at the bottom:
>
> Feb 22 02:15:07 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-7OngiRhduG: open: permission denied
> Feb 22 02:23:31 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-jpxayKBERz: open: permission denied
> Feb 22 02:29:31 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-KvIK8XPZRW: open: permission denied
>
> That says to me that the problem stopped around 2AM last night, no? I think that's about the time I rebooted the server -- I don't remember why. If that's true, something got well of natural causes, and I apologize tremendously for the noise.
Indeed. There's no other way I would interpret it.
> The 2 PIDs could very well be because I had 2 BINDs running for a while trying to figure this out -- one as user bind, and one as root. There's a command in my history file to kill 20061.
But how that's possible? BIND should (pardon the ambiguity) bind to
TCP and UDP sockets to listen them, and second BIND instance should be
denied of this (and therefore - fail to launch).
> 'logwatch --range today' prints (about the DNS dumps):
<skip>
>
> The day isn't over yet, but compared to the last few days, that does seem like a pretty small number of failed dumps.
>
> 'cat /var/log/daemon.log | egrep '^Feb 22.*tmp-' | sort -k9' (sorted on filename to match logwatch's sorting it's lines) prints:
>
> Feb 22 01:57:18 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-18yeqdeUo7: open: permission denied
<skip>
> Feb 22 00:43:19 log named[20117]: dumping master
file: /var/cache/bind/slaves/tmp-yhcq7G3STF: open: permission denied
>
> I think the file names are identical. The first and last are, anyway, and wc -l says they have the same number of lines (24).
I reached the same conclusion.
> And without the sort (effectively sorted on time):
>
> Feb 22 00:02:30 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-X7frzE1EHg: open: permission denied
<skip>
> Feb 22 02:29:31 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-KvIK8XPZRW: open: permission denied
>
> Am I right? That the problem stopped at 2:30 last night?
Indeed. Looks like a reboot took care of it, whatever it was.
> If I am, I have a bigger problem: WTF is going on in my server?
>
> And where/why is BIND writing all those files? I don't see any below /var/cache/bind. And why is BIND trying to dump a master file into the slaves directory?
I'd start with rkhunter check first. Just to be sure.
In situation like this it would be an overkill, but I'd also checked OS
installation with debsums from LiveCD, and the existence
of /etc/ld.so.preload, and /etc/rc.local.
Reco
Reply to: