Re: BIND problem
On Tue, 23 Feb 2016 07:42:59 -0700
Glenn English <ghe@srv.slsware.net> wrote:
>
> > On Feb 23, 2016, at 1:45 AM, Reco <recoverym4n@gmail.com> wrote:
>
> > I'd start with rkhunter check first. Just to be sure.
>
> Checking for enabled inetd services [ Warning ]
>
> That's AmandaClient, the backup software.
Harmless.
> Checking if SSH root access is allowed [ Warning ]
>
> It is, But only with a key. And this is the master DNS server. It's on the DMZ, behind a hardened Cisco router and a Cisco PIX firewall. It's allowed out, but no-one is allowed in unless the server asks first and somebody's replying to the servers request, from the same IP the server sent the query to. I doubt anybody got into it from the 'Net. I get into it with SSH, from the LAN, to check on it.
Well, they *have* to check this stuff. It's harmless in such
environment, of course.
> /usr/bin/unhide.rb [ Warning ]
>
> I have no explanation for that one. But:
>
> root@log:~# /usr/bin/unhide.rb
> Scanning for hidden processes...
> No hidden processes found!
Harmless. You have to whitelist unhide.rb in rkhunter.conf to make it
disappear.
> > In situation like this it would be an overkill, but I'd also checked OS
> > installation with debsums from LiveCD,
>
> I didn't do that because it'd be lots of trouble, and I don't have a live CD (I'd have to download one). And the (Wheezy) kernel has been updated many times, so I doubt it'd match the live CD anyway.
The kernel match is not relevant here, and even a Debian release match
is not (to a degree of compatibility between LiveCD's kernel and this
OS libc). The purpose of LiveCD is to obtain a trusted kernel and
userland from a known good source, preferably with the same
architecture (which is x86_64 I presume).
The reason for this trouble is that the current kernel can be modified
by certain crafted loadable kernel modules, which:
a) Hide rogue processes and/or /etc/ld.so.preload from common binaries
such as 'ls' or 'ps'.
b) Hide its own presence from 'lsmod'.
So far the only visible manifestation of this possible rootkit are
strange files that failed to be created in /var/cache/bind/slaves/.
So, as I wrote earlier - the whole check is probably an overkill.
But looking on a bright side - if such check finds nothing - it's
definitely some obscure local configuration problem.
> > the existence of /etc/ld.so.preload,
>
> root@log:~# ls -a /etc/ | egrep -ir ld.so.preload
>
> Nothing
And it proves nothing by itself sadly. See above and below.
>
> > and /etc/rc.local.
>
> root@log:~# ls -a /etc/ | egrep -ir rc.local
> .cache/mozilla/firefox/n6glp0sg.default/Cache/5/98/17F03d01:<td ><label for="idx_48"><a class='ui_link' href='edit_action.cgi?0+rc%2Elocal'>rc.local</a></label></td>
> .cache/mozilla/firefox/n6glp0sg.default/Cache/5/98/17F03d01:<td ><label for="idx_48">Run /etc/rc.local if it exist</label></td>
>
> Cause for concern? As suggested in the last line, I ran /etc/rc.local -- there was no output.
First things first, unless someone deliberately customized
it, /etc/rc.local should contain exactly one meaningful line - 'exit
0'. Your result shows entirely different thing though.
Second, that result means that somebody run at least once Mozilla
Firefox or Debian Iceweasel on this host as root. Definitely not a
crime against a nature, but definitely a sign of a bad taste. I doubt
that it has something in common with the BIND problem. It also goes
without saying that that particular cache file contained someone's
advice about /etc/rc.local.
Third, grep(1) says that:
-r, --recursive
Read all files under each directory, recursively,
following symbolic links only if they are on the command line. This
is equivalent to the -d recurse option.
So the correct invocation would be 'ls -a /etc | egrep -i rc.local'.
A simple 'cat /etc/rc.local' would be even better. But, that's assuming
that you can trust your current kernel and userland (see above).
Reco
Reply to: