UMGUM.COM (лучше) 

Инсталляция Bind 9 ( Инсталляция сервера доменных имен Bind 9. )

24 марта 2010  (обновлено 31 января 2015)

OS: Debian Lenny.

Устанавливаем необходимые пакеты:

# aptitude install bind9 bind9utils

Инсталлятор создает пользователя и группу "bind", нам это и нужно было; если пользователь и группа не были созданы автоматически - сделаем это сами.

Останавливаем службу named (нам ещё предстоит загнать её в изолированное окружение, на ходу делать это неудобно и не зачем):

# /etc/init.d/bind9 stop

Приступим к переносу службы named в изолированное окружение.


Мне сильно не понравился своей избыточностью конфигурационный файл управления запуском и остановом службы named "/etc/init.d/bind9" и я его безжалостно порезал, возможно утратив при этом некоторые "плюшки" (которые на постоянно работающем и не меняющем свою конфигурацию сервере могут никогда и не понадобится), получив в результате следующее:

#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
OPTIONS="-4 -d 1 -c /etc/bind/named.conf -u bind -t /var/lib/named"
RESOLVCONF=yes
PIDFILE=/var/run/bind/run/named.pid

test -x /usr/sbin/named || exit 0
test -x /usr/sbin/rndc || exit 0

case "$1" in
  start)
    echo "Starting domain name service..."
    start-stop-daemon --start --quiet --exec /usr/sbin/named --pidfile ${PIDFILE} -- $OPTIONS
    echo "..."
  ;;
  stop)
    echo "Stopping domain name service..."
    /usr/sbin/rndc stop
    echo "..."
  ;;
  reload|force-reload)
    echo "Reloading domain name service..."
    /usr/sbin/rndc reload
    echo "..."
  ;;
  restart)
    $0 stop
    sleep 3
    $0 start
  ;;
  *)
    echo "Usage: /etc/init.d/bind9 {start|stop|reload|restart|force-reload}"
    exit 1
  ;;
esac
exit 0

Ещё раз покаюсь за столь не академический подход к написанию управляющего скрипта, но сервер мы настраиваем совершенно чётко понимая, что и от чего хотим, и, по идее, должны заранее обеспечить все, что нужно для функционирования развёртываемых приложений.

Создаем дерево директорий, необходимых для работы:

# mkdir -p /var/lib/named/etc
# mkdir /var/lib/named/dev
# mkdir -p /var/lib/named/var/cache/bind
# mkdir -p /var/lib/named/var/run/bind/run
# mkdir /var/lib/named/var/log

Переместим конфигурационные файлы bind, созданные "по умолчанию" в директории "/etc/bind", на новое месторасположения:

# mv /etc/bind /var/lib/named/etc

Создадим символическую ссылку со старого месторасположения конфигурационных файлов на новое, чтобы при обновлении приложения инсталлятор не рвался заново создавать файлы и директории:

# ln -s /var/lib/named/etc/bind /etc/bind

Создадим необходимые для работы bind файлы устройств:

# mknod /var/lib/named/dev/null c 1 3
# mknod /var/lib/named/dev/random c 1 8

Создадим необходимые для работы bind лог файлы, они нам понадобятся позже, когда будет откорректирован конфигурационный файл:

# touch /var/lib/named/var/log/named.log
# touch /var/lib/named/var/log/security.log

Подправим флаги разрешений на право доступа к созданным нами директориям и файлам:

# chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random
# chown -R bind:bind /var/lib/named/var/*
# chown -R bind:bind /var/lib/named/etc/bind/*
# chown -R bind:bind /var/lib/named/var/log/*

Удаляем ненужные нам файлы и директории из состава конфигурации "по умолчанию", созданные при инсталляции bind9:

# rm -rf /var/cache/bind
# rm -rf /var/run/bind
# rm -rf /var/lib/bind

Запускам bind:

# /etc/init.d/bind9 start

Исполняем следующее:

# ps aux | grep named | grep -v grep

В результате мы должны получит нечто вроде этого, где мы видим, что служба named запущена от непривилегированного пользователя "bind" и в команде запуска присутствует ключ закрытия её в "песочнице":

bind ... /usr/sbin/named -4 -d 1 -c /etc/bind/named.conf -u bind -t /var/lib/named

Проверяем лог файл /var/log/syslog на предмет наличия ошибок, в случае корректного исполнения всего вышеописанного мы имеем неплохие шансы увидеть нечто вроде нижеприведённого, свидетельствующее о нормально запустившемся named в "песочнице":

starting BIND [version] -u bind -t /var/lib/named
found 1 CPU, using 1 worker thread
using up to 4096 sockets
loading configuration from '/etc/bind/named.conf'
max open files (1024) is smaller than max sockets (4096)
using default UDP/IPv4 port range: [1024, 65535]
using default UDP/IPv6 port range: [1024, 65535]
listening on IPv6 interfaces, port 53
listening on IPv4 interface lo, 127.0.0.1#53
listening on IPv4 interface eth0, [ip]#53
listening on IPv4 interface eth1, [ip]#53
...

Все, служба named в изолированном окружении - можно приступать к конфигурированию bind как такового.

Вообще-то, это не совсем полный "chroot", скорее эмуляция такового средствами самого приложения, что мы пытаемся защитить от компрометации. То есть, мы надеемся на корректную отработку приложения, от некорректной работы которого пытаемся защитить другие приложения выносом его в изолированную среду. Сдается мне, что это не совсем правильно. Мы не выносили в изолированное окружение исполняемые файлы и не запирали из в полноценной "песочницы", из которых они не смогут "выбраться" в силу системных ограничений. Так же, при создании полноценного изолированного окружения нам пришлось бы давать указания службе системы журналирования сообщений (обычно это syslog), о том, чтобы она следила ещё и за состоянием устройства "/chroot/dev/log", так как запертое в "песочнице" приложение не смогло бы обратится к "/dev/log". Пока ограничимся проделанной работой по изолированию приложения, а позже обязательно загоним bind в полный "chroot".


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )