Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #164479 > unrolled thread

BIND problem

Started byGlenn English <ghe@srv.slsware.net>
First post2016-02-22 11:00 +0100
Last post2016-02-23 00:00 +0100
Articles 15 — 2 participants

Back to article view | Back to linux.debian.user

Contents

  BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-22 11:00 +0100
    Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-22 11:20 +0100
      Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-22 21:30 +0100
        Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-22 22:00 +0100
          Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-22 23:00 +0100
            Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-22 23:20 +0100
              Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-23 00:00 +0100
                Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-23 05:10 +0100
                  Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-23 09:50 +0100
                    Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-23 16:10 +0100
                      Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-23 17:00 +0100
                        Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-23 22:30 +0100
                          Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-23 22:50 +0100
                            Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-24 05:20 +0100
              Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-23 00:00 +0100

#164479 — BIND problem

FromGlenn English <ghe@srv.slsware.net>
Date2016-02-22 11:00 +0100
SubjectBIND problem
Message-ID<r4VrB-3HO-7@gated-at.bofh.it>
I'm seeing lots of:

> Feb 21 23:32:24 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-I5cJjYH7fV: open: permission denied
> Feb 21 23:36:54 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-zsVXbHkEG1: open: permission denied
> Feb 21 23:46:00 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-ngGrdGrU2a: open: permission denied
> Feb 21 23:49:26 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-Q0vQCUg5xd: open: permission denied
> Feb 21 23:58:36 log named[20061]: zone richeyrentals.com/IN: refresh: could not set file modification time of '/var/cache/bind/slaves/db.richeyrentals.com': permission denied
> Feb 21 23:59:56 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-Ef1P4JJ7WK: open: permission denied
> Feb 22 00:02:30 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-X7frzE1EHg: open: permission denied
> Feb 22 00:14:26 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-Mvis5kMjqB: open: permission denied
> Feb 22 00:14:54 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-5cVqqTAnb6: open: permission denied
> Feb 22 00:25:31 log named[20117]: zone richeyrentals.com/IN: refresh: could not set file modification time of '/var/cache/bind/slaves/db.richeyrentals.com': permission denied
> Feb 22 00:25:48 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-5n3f6qn0Cj: open: permission denied
> Feb 22 00:29:50 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-qbxXuXSlvZ: open: permission denied
> Feb 22 00:38:07 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-n99ZL1tdSc: open: permission denied
> Feb 22 00:43:19 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-yhcq7G3STF: open: permission denied
> Feb 22 00:51:46 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-8m09QHZPqR: open: permission denied
> Feb 22 00:53:20 log named[20061]: zone richeyrentals.com/IN: refresh: could not set file modification time of '/var/cache/bind/slaves/db.richeyrentals.com': permission denied

in my log.

I looked on the web, and no suggestion helped. Except one: one of then said his worked when he ran bind (aka named) as root. I tried that and sure enough, it 'fixed' the problem. Until monit somehow noticed the DNS wasn't running and started it from /etc/init.d (I'm still running Wheezy). 

It happens only on the master DNS server -- the slaves do their dumps successfully, or maybe they don't try.

I tried su -'ing from root to user bind (after giving bind a shell). No joy.

Everything in /var/cache/bind is owned by bind:bind, it's all owner and group writable, root manages to write the files, there are no complaints about the masters directory (there are also no files called tmp-*** in there), and I'm at a loss as to why there's a problem setting the modification time (touch does it just fine).

Has anyone seen this and fixed it? 

I'm guessing somebody's just kidding about the directory they're trying to write into, and their real directory is owned by user nobody...

-- 
Glenn English

[toc] | [next] | [standalone]

#164480

FromReco <recoverym4n@gmail.com>
Date2016-02-22 11:20 +0100
Message-ID<r4VKV-47A-11@gated-at.bofh.it>
In reply to#164479
	Hi.

On Mon, 22 Feb 2016 02:35:52 -0700
Glenn English <ghe@srv.slsware.net> wrote:

> I'm seeing lots of:
> 
> > Feb 21 23:32:24 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-I5cJjYH7fV: open: permission denied
> > Feb 21 23:36:54 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-zsVXbHkEG1: open: permission denied
> > Feb 21 23:46:00 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-ngGrdGrU2a: open: permission denied
> > Feb 21 23:49:26 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-Q0vQCUg5xd: open: permission denied
> > Feb 21 23:58:36 log named[20061]: zone richeyrentals.com/IN: refresh: could not set file modification time of '/var/cache/bind/slaves/db.richeyrentals.com': permission denied
> > Feb 21 23:59:56 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-Ef1P4JJ7WK: open: permission denied
> > Feb 22 00:02:30 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-X7frzE1EHg: open: permission denied
> > Feb 22 00:14:26 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-Mvis5kMjqB: open: permission denied
> > Feb 22 00:14:54 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-5cVqqTAnb6: open: permission denied
> > Feb 22 00:25:31 log named[20117]: zone richeyrentals.com/IN: refresh: could not set file modification time of '/var/cache/bind/slaves/db.richeyrentals.com': permission denied
> > Feb 22 00:25:48 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-5n3f6qn0Cj: open: permission denied
> > Feb 22 00:29:50 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-qbxXuXSlvZ: open: permission denied
> > Feb 22 00:38:07 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-n99ZL1tdSc: open: permission denied
> > Feb 22 00:43:19 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-yhcq7G3STF: open: permission denied
> > Feb 22 00:51:46 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-8m09QHZPqR: open: permission denied
> > Feb 22 00:53:20 log named[20061]: zone richeyrentals.com/IN: refresh: could not set file modification time of '/var/cache/bind/slaves/db.richeyrentals.com': permission denied
> 
> in my log.

Please post the output of:

ls -ald /var/cache/bind/slaves

lsattr /var/cache/bind/slaves

getfacl /var/cache/bind/slaves


Also, do you have SELinux enabled?

Reco

[toc] | [prev] | [next] | [standalone]

#164515

FromGlenn English <ghe@srv.slsware.net>
Date2016-02-22 21:30 +0100
Message-ID<r55hg-2Mm-9@gated-at.bofh.it>
In reply to#164480
> On Feb 22, 2016, at 3:14 AM, Reco <recoverym4n@gmail.com> wrote:
> 
> Please post the output of:
> 
> ls -ald /var/cache/bind/slaves

drwxrwxr-x 2 bind bind 4096 Feb  5 07:52 /var/cache/bind/slaves

> lsattr /var/cache/bind/slaves

-------------e-- /var/cache/bind/slaves/db.172.16.0
-------------e-- /var/cache/bind/slaves/db.richeyrentals.com
-------------e-- /var/cache/bind/slaves/db.richeyrentals.dmz
-------------e-- /var/cache/bind/slaves/db.richeyrentals.lan

> getfacl /var/cache/bind/slaves

getfacl: Removing leading '/' from absolute path names
# file: var/cache/bind/slaves
# owner: bind
# group: bind
user::rwx
group::rwx
other::r-x

> Also, do you have SELinux enabled?

root@log:/etc# egrep -ir SELinux *
dbus-1/session.conf:  <include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
dbus-1/system.conf:  <include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
init.d/x11-common:  # Restore file security context (SELinux).
init.d/udev:    # set the SELinux context for devices created in the initramfs
init.d/checkroot.sh:	if selinux_enabled && [ -x /sbin/restorecon ] && [ -r /etc/mtab ]
Binary file ld.so.cache matches
pam.d/login:# SELinux needs to be the first session rule. This ensures that any 
pam.d/login:# When the module is present, "required" would be sufficient (When SELinux
pam.d/login:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
pam.d/login:# SELinux needs to intervene at login time to ensure that the process
pam.d/login:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
pam.d/login:# When the module is present, "required" would be sufficient (When SELinux
pam.d/sshd:# Set up SELinux capabilities (need modified pam)
pam.d/sshd:# session  required     pam_selinux.so multiple
security/sepermit.conf:#        - a SELinux user name, with %seuser syntax
selinux/semanage.conf:# Specify how libsemanage will interact with a SELinux policy manager.
selinux/semanage.conf:#  "source"     - libsemanage manipulates a source SELinux policy
webmin/useradmin/config:selinux_con=user_u:object_r:user_home_dir_t

I think so...

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#164517

FromReco <recoverym4n@gmail.com>
Date2016-02-22 22:00 +0100
Message-ID<r55Ki-2Wr-7@gated-at.bofh.it>
In reply to#164515
	Hi.

On Mon, 22 Feb 2016 13:07:44 -0700
Glenn English <ghe@srv.slsware.net> wrote:

> 
> > On Feb 22, 2016, at 3:14 AM, Reco <recoverym4n@gmail.com> wrote:
> > 
> > Please post the output of:
> > 
> > ls -ald /var/cache/bind/slaves
> 
> drwxrwxr-x 2 bind bind 4096 Feb  5 07:52 /var/cache/bind/slaves
> 
> > lsattr /var/cache/bind/slaves
> 
> -------------e-- /var/cache/bind/slaves/db.172.16.0
> -------------e-- /var/cache/bind/slaves/db.richeyrentals.com
> -------------e-- /var/cache/bind/slaves/db.richeyrentals.dmz
> -------------e-- /var/cache/bind/slaves/db.richeyrentals.lan
> 
> > getfacl /var/cache/bind/slaves
> 
> getfacl: Removing leading '/' from absolute path names
> # file: var/cache/bind/slaves
> # owner: bind
> # group: bind
> user::rwx
> group::rwx
> other::r-x

Ok, so nothing out of place here.


> > Also, do you have SELinux enabled?
> 
> root@log:/etc# egrep -ir SELinux *
<skip> 
> I think so...

No, that's not how you check it. Every Debian system has those records.
I meant something like 'ls -alZ /'.


And having looking on all those permissions - I have an idea. Two,
actually.

First, what does contents of /etc/default/bind9 look like?

Second, can you install auditd please and run
'auditctl -w /var/cache/bind/slaves/ -p wa' afterward?
A contents of /var/log/audit/audit.log would be invaluable to
troubleshoot this problem. Of course, it would be also required for
bind to fail to dump a zone at least once. 

Reco

[toc] | [prev] | [next] | [standalone]

#164520

FromGlenn English <ghe@srv.slsware.net>
Date2016-02-22 23:00 +0100
Message-ID<r56Gm-3Cv-5@gated-at.bofh.it>
In reply to#164517
> On Feb 22, 2016, at 1:59 PM, Reco <recoverym4n@gmail.com> wrote:
> 
> No, that's not how you check it. Every Debian system has those records.
> I meant something like 'ls -alZ /'.

drwxr-xr-x  25 root   root    ?  4096 Jun  6  2014 .
drwxr-xr-x  25 root   root    ?  4096 Jun  6  2014 ..
drwxr-xr-x   2 root   root    ?  4096 Feb 19 10:26 bin
drwxr-xr-x   3 root   root    ?  4096 Jan  7 21:40 boot
drwxr-xr-x  14 root   root    ?  3380 Feb 22 02:34 dev
drwxr-xr-x 127 root   root    ? 12288 Feb 22 14:12 etc
drwxr-xr-x   3 root   root    ?  4096 Aug 31 00:42 home
lrwxrwxrwx   1 root   root    ?    30 Oct 11  2013 initrd.img -> /boot/initrd.img-3.2.0-4-amd64
drwxr-xr-x  15 root   root    ?  4096 Mar 17  2014 lib
drwxr-xr-x   2 root   root    ?  4096 Feb 17 07:36 lib64
drwx------   2 root   root    ? 16384 Oct 11  2013 lost+found
drwxr-xr-x   3 root   root    ?  4096 Oct 11  2013 media
drwxr-xr-x   2 root   root    ?  4096 Jun  2  2013 mnt
drwxr-xr-x   2 root   root    ?  4096 Oct 11  2013 opt
dr-xr-xr-x 149 root   root    ?     0 Feb 22 02:33 proc
drwxr-xr-x   3 root   root    ?  4096 Jun  6  2014 project
drwx------  23 root   root    ?  4096 Feb 21 20:24 root
drwxr-xr-x  22 root   root    ?   960 Feb 22 14:12 run
drwxr-xr-x   2 root   root    ?  4096 Feb 22 14:12 sbin
drwxr-xr-x   2 root   root    ?  4096 Jun 10  2012 selinux
drwxr-xr-x   3 root   root    ?  4096 Oct 11  2013 srv
drwxr-xr-x  13 root   root    ?     0 Feb 22 02:34 sys
drwxrwxrwx   4 nobody nogroup ?  4096 Apr  2  2014 tftpboot
drwxrwxrwt   7 root   root    ?  4096 Feb 22 14:17 tmp
drwxr-xr-x  11 root   root    ?  4096 Oct 11  2013 usr
drwxr-xr-x  14 root   root    ?  4096 Feb  8  2014 var
lrwxrwxrwx   1 root   root    ?    26 Oct 11  2013 vmlinuz -> boot/vmlinuz-3.2.0-4-amd64

> First, what does contents of /etc/default/bind9 look like?

# run resolvconf?
RESOLVCONF=yes

# startup options for the server
### OPTIONS="-u bind"
OPTIONS=" -4 -u bind"

> Second, can you install auditd please

Selecting previously unselected package auditd.
(Reading database ... 72472 files and directories currently installed.)
Unpacking auditd (from .../auditd_1%3a1.7.18-1.1_amd64.deb) ...
Processing triggers for man-db ...
Setting up auditd (1:1.7.18-1.1) ...

> and run
> 'auditctl -w /var/cache/bind/slaves/ -p wa' afterward?
> A contents of /var/log/audit/audit.log

type=DAEMON_START msg=audit(1456174952.726:9009): auditd start, ver=1.7.18 format=raw kernel=3.2.0-4-amd64 auid=4294967295 pid=18137 res=success
type=CONFIG_CHANGE msg=audit(1456174952.825:2): audit_backlog_limit=320 old=64 auid=4294967295 ses=4294967295 res=1
type=LOGIN msg=audit(1456174953.225:3): login pid=18158 uid=0 old auid=4294967295 new auid=118 old ses=4294967295 new ses=1
type=LOGIN msg=audit(1456174953.301:4): login pid=18183 uid=0 old auid=4294967295 new auid=118 old ses=4294967295 new ses=2
type=LOGIN msg=audit(1456174981.336:5): login pid=18250 uid=0 old auid=4294967295 new auid=1 old ses=4294967295 new ses=3
type=CONFIG_CHANGE msg=audit(1456174992.612:6): auid=4294967295 ses=4294967295 op="add rule" key=(null) list=4 res=1

> it would be also required for
> bind to fail to dump a zone at least once. 

I hadn't read that part until after I ran auditctl. I think there'd been several failed dumps before then, so I looked at the logs in hopes of giving you proof, but auditctl kept saying "Error sending add rule data request (Rule exists)". So I uninstalled --purge'ed it (and deleted it's log) and reinstalled it and ran 'date ; auditctl -w /var/cache/bind/slaves/ -p wa'. That printed the date and nothing else. I ran auditctl again, by itself, and it repeated the error statement.

The logs say there have been many dump failures, so I'm pretty sure auditctl was run after a failed dump. I can't prove it, though.

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#164524

FromReco <recoverym4n@gmail.com>
Date2016-02-22 23:20 +0100
Message-ID<r56ZJ-44s-25@gated-at.bofh.it>
In reply to#164520
On Mon, 22 Feb 2016 14:33:03 -0700
Glenn English <ghe@srv.slsware.net> wrote:

> 
> > On Feb 22, 2016, at 1:59 PM, Reco <recoverym4n@gmail.com> wrote:
> > 
> > No, that's not how you check it. Every Debian system has those records.
> > I meant something like 'ls -alZ /'.
> 
> drwxr-xr-x  25 root   root    ?  4096 Jun  6  2014 .
> drwxr-xr-x  25 root   root    ?  4096 Jun  6  2014 ..
> drwxr-xr-x   2 root   root    ?  4096 Feb 19 10:26 bin
> drwxr-xr-x   3 root   root    ?  4096 Jan  7 21:40 boot
> drwxr-xr-x  14 root   root    ?  3380 Feb 22 02:34 dev
> drwxr-xr-x 127 root   root    ? 12288 Feb 22 14:12 etc
> drwxr-xr-x   3 root   root    ?  4096 Aug 31 00:42 home
> lrwxrwxrwx   1 root   root    ?    30 Oct 11  2013 initrd.img -> /boot/initrd.img-3.2.0-4-amd64
> drwxr-xr-x  15 root   root    ?  4096 Mar 17  2014 lib
> drwxr-xr-x   2 root   root    ?  4096 Feb 17 07:36 lib64
> drwx------   2 root   root    ? 16384 Oct 11  2013 lost+found
> drwxr-xr-x   3 root   root    ?  4096 Oct 11  2013 media
> drwxr-xr-x   2 root   root    ?  4096 Jun  2  2013 mnt
> drwxr-xr-x   2 root   root    ?  4096 Oct 11  2013 opt
> dr-xr-xr-x 149 root   root    ?     0 Feb 22 02:33 proc
> drwxr-xr-x   3 root   root    ?  4096 Jun  6  2014 project
> drwx------  23 root   root    ?  4096 Feb 21 20:24 root
> drwxr-xr-x  22 root   root    ?   960 Feb 22 14:12 run
> drwxr-xr-x   2 root   root    ?  4096 Feb 22 14:12 sbin
> drwxr-xr-x   2 root   root    ?  4096 Jun 10  2012 selinux
> drwxr-xr-x   3 root   root    ?  4096 Oct 11  2013 srv
> drwxr-xr-x  13 root   root    ?     0 Feb 22 02:34 sys
> drwxrwxrwx   4 nobody nogroup ?  4096 Apr  2  2014 tftpboot
> drwxrwxrwt   7 root   root    ?  4096 Feb 22 14:17 tmp
> drwxr-xr-x  11 root   root    ?  4096 Oct 11  2013 usr
> drwxr-xr-x  14 root   root    ?  4096 Feb  8  2014 var
> lrwxrwxrwx   1 root   root    ?    26 Oct 11  2013 vmlinuz -> boot/vmlinuz-3.2.0-4-amd64

So, the result has question marks instead of SELinux labels. This rules
out SELinux completely. Audit log would include SELinux violations
anyway, but still - simplest methods are the best :)


> > First, what does contents of /etc/default/bind9 look like?
> 
> # run resolvconf?
> RESOLVCONF=yes
> 
> # startup options for the server
> ### OPTIONS="-u bind"
> OPTIONS=" -4 -u bind"

And again, your usual run-of-the-mill Debian bind configuration file,
nothing to see here.


> > Second, can you install auditd please
> 
> Selecting previously unselected package auditd.
> (Reading database ... 72472 files and directories currently installed.)
> Unpacking auditd (from .../auditd_1%3a1.7.18-1.1_amd64.deb) ...
> Processing triggers for man-db ...
> Setting up auditd (1:1.7.18-1.1) ...
> 
> > and run
> > 'auditctl -w /var/cache/bind/slaves/ -p wa' afterward?
> > A contents of /var/log/audit/audit.log
> 
> type=DAEMON_START msg=audit(1456174952.726:9009): auditd start, ver=1.7.18 format=raw kernel=3.2.0-4-amd64 auid=4294967295 pid=18137 res=success
> type=CONFIG_CHANGE msg=audit(1456174952.825:2): audit_backlog_limit=320 old=64 auid=4294967295 ses=4294967295 res=1
> type=LOGIN msg=audit(1456174953.225:3): login pid=18158 uid=0 old auid=4294967295 new auid=118 old ses=4294967295 new ses=1
> type=LOGIN msg=audit(1456174953.301:4): login pid=18183 uid=0 old auid=4294967295 new auid=118 old ses=4294967295 new ses=2
> type=LOGIN msg=audit(1456174981.336:5): login pid=18250 uid=0 old auid=4294967295 new auid=1 old ses=4294967295 new ses=3
> type=CONFIG_CHANGE msg=audit(1456174992.612:6): auid=4294967295 ses=4294967295 op="add rule" key=(null) list=4 res=1
> 
> > it would be also required for
> > bind to fail to dump a zone at least once. 
> 
> I hadn't read that part until after I ran auditctl. I think there'd been several failed dumps before then, so I looked at the logs in hopes of giving you proof, but auditctl kept saying "Error sending add rule data request (Rule exists)". So I uninstalled --purge'ed it (and deleted it's log) and reinstalled it and ran 'date ; auditctl -w /var/cache/bind/slaves/ -p wa'. That printed the date and nothing else. I ran auditctl again, by itself, and it repeated the error statement.

Sorry, I forgot to add. To clear out audit rules you need to issue
'auditctl -D'. To view existing ones you need to issue 'auditctl -l'.
Reinstalling the package would clear the rules along the way, of
course.


> The logs say there have been many dump failures, so I'm pretty sure auditctl was run after a failed dump. I can't prove it, though.

And that leaves us exactly one possible explanation for this.

/var has 755 permissions, and owner:group of root.
/var/cache/bind/slaves has 775 permission, and owner:group of bind.

Since bind user is unable to write to /var/cache/bind/slaves, and audit
is unable to catch failed writes there - that can only mean that bind
user is unable to chdir to either /var/cache or /var/cache/bind.

So, what permissions does /var/cache and /var/cache/bind have?

Reco

[toc] | [prev] | [next] | [standalone]

#164527

FromReco <recoverym4n@gmail.com>
Date2016-02-23 00:00 +0100
Message-ID<r57Cq-4w9-15@gated-at.bofh.it>
In reply to#164524
On Mon, 22 Feb 2016 15:33:54 -0700
Glenn English <ghe@srv.slsware.net> wrote:

> 
> > On Feb 22, 2016, at 3:16 PM, Reco <recoverym4n@gmail.com> wrote:
> > 
> > So, what permissions does /var/cache and /var/cache/bind have?
> 
> root@log:~# ls -lh /var/cache/bind
> total 48K
> -rw-rw-r-- 1 bind bind  221 Oct 12  2013 managed-keys.bind
> -rw-rw-r-- 1 bind bind  512 Oct 12  2013 managed-keys.bind.jnl
> drwxrwxr-x 2 bind bind 4.0K Feb 16 19:19 masters
> -rw-rw-r-- 1 bind bind  30K Feb 22 00:32 named_dump.db
> drwxrwxr-x 2 bind bind 4.0K Feb  5 07:52 slaves
> 
> root@log:~# ls -lh /var/cache/
> total 48K
> drwxr-xr-x  3 root root 4.0K Feb  8  2014 apache2
> drwxr-xr-x  3 root root 4.0K Feb 22 14:12 apt
> drwxr-xr-x  4 bind bind 4.0K Feb 22 02:34 bind
> drwxrwxr-x  3 root lp   4.0K Feb 22 06:25 cups
> drwxr-xr-x  2 root root 4.0K Feb 22 14:12 debconf
> drwxr-xr-x  2 root root 4.0K Oct 11  2013 dictionaries-common
> drwxr-xr-x  2 root root 4.0K Oct 29  2013 fontconfig
> drwxr-xr-x  2 root root 4.0K Nov 24  2012 git
> drwx------  2 root root 4.0K Feb 17 07:36 ldconfig
> drwxr-sr-x 38 man  root 4.0K Feb 22 14:12 man
> drwxr-xr-x  2 root root 4.0K Jan 16  2012 pm-utils
> drwxr-xr-x  2 root root 4.0K Aug 15  2013 samba

OK, three small details are missing from the puzzle.

First one is 'ls -ald /var/cache'.

Second one is 'sudo -u touch /var/cache/bind/slaves/1'.
'su -l bind -c "touch /var/cache/bind/slaves/1"' should do it too since
you have an interactive login shell for bind.

Third one (hey, you never know) is 'ls -ald /'.

Reco

[toc] | [prev] | [next] | [standalone]

#164532

FromGlenn English <ghe@srv.slsware.net>
Date2016-02-23 05:10 +0100
Message-ID<r5csq-8gx-13@gated-at.bofh.it>
In reply to#164527
> 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.)

> '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 /

...

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. 

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.

'logwatch --range today' prints (about the DNS dumps):

    dumping master file: /var/cache/bind/slaves/tmp-18yeqdeUo7: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-5cVqqTAnb6: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-5n3f6qn0Cj: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-7OngiRhduG: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-8m09QHZPqR: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-93yzSn2HVG: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-KQi00ADskK: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-KnYb1BM7ho: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-KvIK8XPZRW: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-Mvis5kMjqB: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-NB1hVFYTQ3: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-RbEDOfprSt: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-Tr7TNyn2pB: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-X7frzE1EHg: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-fHVyGM1SqQ: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-fSPdEwQTGO: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-h28gNDyR7n: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-jpxayKBERz: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-n99ZL1tdSc: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-pPGgsIYF9T: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-qbxXuXSlvZ: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-ucvOB7hKDt: open: permission denied: 1 Time(s)
    dumping master file: /var/cache/bind/slaves/tmp-yhcq7G3STF: open: permission denied: 1 Time(s)

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
Feb 22 00:14:54 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-5cVqqTAnb6: open: permission denied
Feb 22 00:25:48 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-5n3f6qn0Cj: open: permission denied
Feb 22 02:15:07 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-7OngiRhduG: open: permission denied
Feb 22 00:51:46 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-8m09QHZPqR: open: permission denied
Feb 22 01:24:08 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-93yzSn2HVG: open: permission denied
Feb 22 01:42:43 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-fHVyGM1SqQ: open: permission denied
Feb 22 00:57:44 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-fSPdEwQTGO: open: permission denied
Feb 22 01:31:03 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-h28gNDyR7n: 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 01:48:41 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-KnYb1BM7ho: open: permission denied
Feb 22 01:17:57 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-KQi00ADskK: open: permission denied
Feb 22 02:29:31 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-KvIK8XPZRW: open: permission denied
Feb 22 00:14:26 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-Mvis5kMjqB: open: permission denied
Feb 22 00:38:07 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-n99ZL1tdSc: open: permission denied
Feb 22 01:37:22 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-NB1hVFYTQ3: open: permission denied
Feb 22 02:01:07 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-pPGgsIYF9T: open: permission denied
Feb 22 00:29:50 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-qbxXuXSlvZ: open: permission denied
Feb 22 02:10:34 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-RbEDOfprSt: open: permission denied
Feb 22 01:06:38 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-Tr7TNyn2pB: open: permission denied
Feb 22 01:11:35 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-ucvOB7hKDt: open: permission denied
Feb 22 00:02:30 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-X7frzE1EHg: open: permission denied
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).

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
Feb 22 00:14:26 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-Mvis5kMjqB: open: permission denied
Feb 22 00:14:54 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-5cVqqTAnb6: open: permission denied
Feb 22 00:25:48 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-5n3f6qn0Cj: open: permission denied
Feb 22 00:29:50 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-qbxXuXSlvZ: open: permission denied
Feb 22 00:38:07 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-n99ZL1tdSc: open: permission denied
Feb 22 00:43:19 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-yhcq7G3STF: open: permission denied
Feb 22 00:51:46 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-8m09QHZPqR: open: permission denied
Feb 22 00:57:44 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-fSPdEwQTGO: open: permission denied
Feb 22 01:06:38 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-Tr7TNyn2pB: open: permission denied
Feb 22 01:11:35 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-ucvOB7hKDt: open: permission denied
Feb 22 01:17:57 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-KQi00ADskK: open: permission denied
Feb 22 01:24:08 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-93yzSn2HVG: open: permission denied
Feb 22 01:31:03 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-h28gNDyR7n: open: permission denied
Feb 22 01:37:22 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-NB1hVFYTQ3: open: permission denied
Feb 22 01:42:43 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-fHVyGM1SqQ: open: permission denied
Feb 22 01:48:41 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-KnYb1BM7ho: open: permission denied
Feb 22 01:57:18 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-18yeqdeUo7: open: permission denied
Feb 22 02:01:07 log named[20117]: dumping master file: /var/cache/bind/slaves/tmp-pPGgsIYF9T: open: permission denied
Feb 22 02:10:34 log named[20061]: dumping master file: /var/cache/bind/slaves/tmp-RbEDOfprSt: open: permission denied
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

Am I right? That the problem stopped at 2:30 last night? 

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?

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#164535

FromReco <recoverym4n@gmail.com>
Date2016-02-23 09:50 +0100
Message-ID<r5gPo-2MH-5@gated-at.bofh.it>
In reply to#164532
	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

[toc] | [prev] | [next] | [standalone]

#164549

FromGlenn English <ghe@srv.slsware.net>
Date2016-02-23 16:10 +0100
Message-ID<r5mL7-7at-13@gated-at.bofh.it>
In reply to#164535
> 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.

    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.

    /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!

> 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 existence of /etc/ld.so.preload,

root@log:~# ls -a /etc/ | egrep -ir ld.so.preload

Nothing

> 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.

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#164552

FromReco <recoverym4n@gmail.com>
Date2016-02-23 17:00 +0100
Message-ID<r5nxv-7tJ-5@gated-at.bofh.it>
In reply to#164549
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

[toc] | [prev] | [next] | [standalone]

#164582

FromGlenn English <ghe@srv.slsware.net>
Date2016-02-23 22:30 +0100
Message-ID<r5sGS-2L7-3@gated-at.bofh.it>
In reply to#164552
> On Feb 23, 2016, at 8:56 AM, Reco <recoverym4n@gmail.com> wrote:
> 
> First things first, unless someone deliberately customized
> it, /etc/rc.local should contain exactly one meaningful line - 'exit
> 0'.

It does. See below.

> Your result shows entirely different thing though.

Well, I just asked egrep to look for the string 'rc.local' anywhere in a filename in /etc. And it found what look to me like a couple hidden mozilla files. In the list of names, not in the execution of the files.

> 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.

That would be me, I'm afraid. IIRC, I thought I was logged into a different computer. It's a vague memory from a long time ago.

> A simple 'cat /etc/rc.local' would be even better.

root@log:~# cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

exit 0

> But, that's assuming
> that you can trust your current kernel and userland (see above).

Are you saying it would be worthwhile to compare my kernel modules to those in a live CD? Or is that considered overkill and probably not necessary?

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#164584

FromReco <recoverym4n@gmail.com>
Date2016-02-23 22:50 +0100
Message-ID<r5t0f-2Ub-19@gated-at.bofh.it>
In reply to#164582
On Tue, 23 Feb 2016 14:04:52 -0700
Glenn English <ghe@srv.slsware.net> wrote:

> 
> > On Feb 23, 2016, at 8:56 AM, Reco <recoverym4n@gmail.com> wrote:
> > 
> > First things first, unless someone deliberately customized
> > it, /etc/rc.local should contain exactly one meaningful line - 'exit
> > 0'.
> 
> It does. See below.
> 
> > Your result shows entirely different thing though.
> 
> Well, I just asked egrep to look for the string 'rc.local' anywhere in a filename in /etc. And it found what look to me like a couple hidden mozilla files. In the list of names, not in the execution of the files.

'-r' flag forced grep to do a different thing - take a contents
of /etc, discard it, and *then* search your current working dir
(which happened to be /root) recursively (and case-insensitive) for
'rc.local'. Any other way you'd see /etc/rc.local in the result of grep.


> > A simple 'cat /etc/rc.local' would be even better.
> 
> root@log:~# cat /etc/rc.local
> #!/bin/sh -e
> #
> # rc.local
> #
> # This script is executed at the end of each multiuser runlevel.
> # Make sure that the script will "exit 0" on success or any other
> # value on error.
> #
> # In order to enable or disable this script just change the execution
> # bits.
> #
> # By default this script does nothing.
> 
> exit 0

Nothing unusual, but:


> > But, that's assuming
> > that you can trust your current kernel and userland (see above).
> 
> Are you saying it would be worthwhile to compare my kernel modules to those in a live CD? Or is that considered overkill and probably not necessary?

Why, it's worth a shot. But doing it by hand would be
counter-productive. They have invented 'debsums' for cases like this,
after all.

A small howto follows:

1) Boot from LiveCD.

2) Mount hosts' root and /var (if it's a different filesystem)
somewhere. Something like this:

mount -o ro,noexec /dev/sda1 /mnt
mount -o ro,noexec /dev/sda2 /mnt/var

3) Run LiveCD's debsums like this:

debsums -r /mnt -d /mnt/var/lib/dpkg -c

It's important that you should run LiveCD's debsums, not hosts' one.


4) Check for any kernel module out of place like this:

find /mnt/lib/modules -type f | xargs dpkg --root=/mnt -S


5) And, while you're at it, check for real contents of /etc/rc.local,
and for /etc/ld.so.preload.

Reco

[toc] | [prev] | [next] | [standalone]

#164585

FromGlenn English <ghe@srv.slsware.net>
Date2016-02-24 05:20 +0100
Message-ID<r5z5H-7tx-77@gated-at.bofh.it>
In reply to#164584
> On Feb 23, 2016, at 2:46 PM, Reco <recoverym4n@gmail.com> wrote:
> 
> Why, it's worth a shot. But doing it by hand would be
> counter-productive. They have invented 'debsums' for cases like this,
> after all.

OK. Sounds reasonable. I'll try it in the morning. 

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#164529

FromGlenn English <ghe@srv.slsware.net>
Date2016-02-23 00:00 +0100
Message-ID<r57Cq-4w9-17@gated-at.bofh.it>
In reply to#164524
> On Feb 22, 2016, at 3:16 PM, Reco <recoverym4n@gmail.com> wrote:
> 
> So, what permissions does /var/cache and /var/cache/bind have?

root@log:~# ls -lh /var/cache/bind
total 48K
-rw-rw-r-- 1 bind bind  221 Oct 12  2013 managed-keys.bind
-rw-rw-r-- 1 bind bind  512 Oct 12  2013 managed-keys.bind.jnl
drwxrwxr-x 2 bind bind 4.0K Feb 16 19:19 masters
-rw-rw-r-- 1 bind bind  30K Feb 22 00:32 named_dump.db
drwxrwxr-x 2 bind bind 4.0K Feb  5 07:52 slaves

root@log:~# ls -lh /var/cache/
total 48K
drwxr-xr-x  3 root root 4.0K Feb  8  2014 apache2
drwxr-xr-x  3 root root 4.0K Feb 22 14:12 apt
drwxr-xr-x  4 bind bind 4.0K Feb 22 02:34 bind
drwxrwxr-x  3 root lp   4.0K Feb 22 06:25 cups
drwxr-xr-x  2 root root 4.0K Feb 22 14:12 debconf
drwxr-xr-x  2 root root 4.0K Oct 11  2013 dictionaries-common
drwxr-xr-x  2 root root 4.0K Oct 29  2013 fontconfig
drwxr-xr-x  2 root root 4.0K Nov 24  2012 git
drwx------  2 root root 4.0K Feb 17 07:36 ldconfig
drwxr-sr-x 38 man  root 4.0K Feb 22 14:12 man
drwxr-xr-x  2 root root 4.0K Jan 16  2012 pm-utils
drwxr-xr-x  2 root root 4.0K Aug 15  2013 samba

-- 
Glenn English

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web