Re: [cobalt-users] Running Bind as non Root

["Paul" <paul@xxxxxxxxxxxxx>]

<snip>
Subject: [cobalt-users] Running Bind as non Root
> Hi,
>  I just installed bind-update.pkg  and it runs under user "root". I heard
that named should not run as user "root". Could someone
> provide an alterative answer and maybe a resolution?>
> thanks
> Ja

Hi Ja try this, is not my package, thanks to R Perry for that but seems to
work fine on my Raq3 and easy to uninstall if problems. Should solve all
your worries, but note disclaimer.

Have posted old E-mail from Rupert with all details, see below. LONG!

Paul

Many people will recall that a large number of us were hacked in
February via a bug in BIND version 8.2.2 (the name daemon on the RAQ)
which allowed a buffer overflow to be exploited remotely, giving root
access to the hacker.  Although there has been much talk of how to
cleanup after the hack, not much has been said about how to prevent
such an attack from succeeding again in future.

By now, everyone who is running a name server on their machine should
be running the latest Cobalt version of BIND (version 8.2.3).  This
is good, as it prevents any known exploits from being used to hack
into the box.  However, no protection whatsoever is provided for any
future buffer overflow bugs, and undoubtedly someone will find
another one at some point in the future.

So what can be done to try and reduce the impact that these buffer
overflow bugs?  Firstly, it is possible to run the BIND name daemon
as an unprivileged user (I.e. non-root) and secondly BIND can be run
in a chroot jail.  The chroot jail is provided by the operating
system and limits BIND to only being able to operate on files
contained within the jail.  By setting up a jail area of the disk
which only contains the files necessary for BIND to operate, security
is improved, as anyone attempting to break into BIND will not
find /bin/sh or other useful programs.  By implementing these two
measures together, we very substantially reduce the likelihood that
any future hacker will actually be able to break in via BIND.  The
best that they will likely be able to do is crash your BIND daemon,
which you can then easily re-start.

There are also things that you can do to improve the security of
BIND's configuration.  Most hackers running automated hacking
programs such as we saw in February, first find vulnerable systems by
scanning random IP address blocks for machines with port 53 (DNS)
open and then asking the name daemon for its version.  If the version
is vulnerable, then an attack is initiated.  By changing the
configuration of BIND, we can prevent BIND from giving out the
version number to anyone who asks and thus avoid being attacked in
the first place.

Another area where the bind configuration can be tightened is called
recursive queries.  A recursive query is one where your name server
has to ask another name server to get the answer to a question sent
to it.  With recursion turned on (as it is by default), anyone can
ask your name server to lookup any name (e.g. your web server could
be asked to lookup www.amazon.com).  Why is this bad?  Well, apart
from wasting your bandwidth allowance by looking up other people's
names, hackers can use this functionality to get your name server to
query some other name server, which may be under their control.  It
is possible to initiate what is known as a poison DNS attack this
way.  Nevertheless, if you are using your own nameserver as a
caching DNS server for any queries on your RAQ, you still need to
allow recursive queries originating from your own server.

The difficulty with most of the above on the RAQ3, is that they it is
not easy to achieve all the changes listed above and still retain the
ease of maintenance which is offered by the RAQ3 web GUI.  This is
where I believe I can help... Having made these changes to my own
RAQ3 server, I have put together a Cobalt package (secure_named-
1.0.pkg) which implements all of the security measures listed above
automatically.  Better still, once you have installed the package,
you can still continue to maintain your domain information through
the RAQ3 web GUI without any changes.  The package can be installed
the same way as any other Cobalt package by simply installing:

  http://raq76.uk2net.com/secure_named-1.0.pkg

I should point out that all the usual disclaimers apply - There is
absolutely no warranty with this package and you install it
completely at your own risk.

If you decide to install the package, this is what it does:

  - Create a new user and group called 'raqnamed'
  - Create a chroot area for BIND in /home/raqnamed
  - Modify the syslog and named start-up scripts to use the new
    chroot area of the system and the 'raqnamed' user and group
  - Modify the Cobalt web GUI DNS management scripts for use
    with the new chroot area
  - Re-generate the named configuration file using the modified script
  - Re-start syslog and named to bring the chroot'd version of
    named into use

If you don't like the effect of what it has done to your server, you
can run the uninstall script which returns the system back to its
previous state.  The uninstall script is installed at:

  /var/lib/cobalt/uninstallers/secure-named-1.0.uninst

The installation itself creates a log file
at /tmp/secure_named_install.log.  If there are any problems with the
installation, you should look at this file first.

I have been running my own DNS server with the changes for several
days now with no problems.  As part of the testing, I have repeatedly
installed, uninstalled and then re-installed, so I am reasonably
happy that all of the install/uninstall process works OK.  I have
tested zone transfers both in and out successfully where my RAQ has
acted as both a primary and secondary name server with no problems.

One final point of note - The "named" start-up scripts are smart
enough to pick-up any new versions of BIND that are installed on the
RAQ and automatically copy them across to the chroot'd area.  This
should make future upgrades of BIND straightforward.

Ideally, what is needed now is for some of the more knowledgeable and
braver people to look at and test the package further.  Then,
hopefully everyone who is running a DNS server on their RAQs will
install it, as it should make everyone's RAQs a lot more secure
against future attacks than they are at present.

Any takers?

Regards,

Rupert.

One thing I forgot to mention - How do you tell whether it has worked
or not?  Fairly simple - Run 'ps -ef | grep named' from the command
line and you should see something like this:

root@raq76 ~> ps -ef | grep named
root     24949     1  0 17:26 00:00:00 syslogd -m 0 a /home/raqnamed/d
raqnamed 25045     1  0 17:26 00:00:00 /home/raqnamed/usr/sbin/named -
u
root      2944  2929  0 19:56 pts/4    00:00:00 grep named
root@raq76 ~>

The second line shows user name 'raqnamed' instead of 'root'.  You
can also see the following entries when named starts-up in your log
(/var/log/messages), which is a bit more conclusive that it is in
fact working:

root@raq76 ~> tail /var/log/messages
<snip>
Apr 30 17:26:24 raq76 named[25045]: chrooted to /home/raqnamed
Apr 30 17:26:24 raq76 named[25045]: group = raqnamed
Apr 30 17:26:24 raq76 named[25045]: user = raqnamed
Apr 30 17:26:24 raq76 named[25045]: Ready to answer queries.
root@raq76 ~>