dns

DNSSEC на практике у регистратора доменов

Февраль 25th, 2013 |

Автор: wtmp

Историческая справка

Система доменных имён (DNS) является одним из важнейших и основных интернет-сервисов, однако на момент её разработки безопасность не была главной целью. С развитием Интернет, однако, обнаружились и уязвимости в системе DNS. Достоверность ответа DNS сервера не проверяется, что позволяет подменить ответ сервера, перенаправив запрос пользователя на произвольный IP адрес. Уязвимы оказались и кэширующие DNS серверы интернет-провайдеров из-за возможности заполнения кэша DNS сервера данными, не исходящими от авторитетного DNS источника (атака Каминского).

Нельзя, впрочем, сказать, что о безопасности DNS вообще не задумывались до текущего времени. Серьёзные недостатки в безопасности этой системы были выявлены ещё в 1990 году Стивом Белловином (Steve Bellovin). Исследования в этой области начались со времён публикации доклада в 1995 году, что вызвало публикацию IETF первых спецификаций на эту тему (RFC 2065) в 1997 году. Первые попытки реализации этой спецификации привели к появлению новой спецификации (RFC 2535) в 1999 году. Именно на спецификации IETF RFC 2535 и была запланирована реализация DNSSEC, однако у этой спецификации были очень серьёзные проблемы с масштабированием на весь интернет. К 2001 году стало окончательно ясно, что эта спецификация была непригодна для крупных сетей. Это, в свою очередь, вызвало возникновение новых спецификаций (RFC 4033, 4034 4035) с принципиальными изменениями DNSSEC (DNSSEC-bis), новая версия которой устраняет основную проблему предыдущей реализации и, хотя в новой спецификации клиентам и необходимо совершать дополнительные действия для проверки ключей, тем не менее вполне пригодна для практического применения.

К сожалению, как это обычно и случается, недостатки DNSSEC являются продолжением её достоинств. Подписание и проверка данных DNS создают дополнительные накладные расходы, что отрицательно сказывается на производительности сети и серверов. К примеру, в среднем зона DNSSEC в 7-10 больше по размеру своего DNS эквивалента. Генерация и проверка подписей отнимает значительное время ЦПУ. Подписи и ключи занимают на порядок больше места на диске и в оперативной памяти, чем сами данные.

Впрочем, работа над DNSSEC еще не завершена, однако любая организация, активно использующая Internet, уже должна рассматривать DNSSEC в качестве важнейшего компонента своей инфраструктуры защиты. Протокол DNS по-прежнему уязвим для злоупотреблений.

Наши дни

Теперь нужно понять ненужность данной технологии в рунете. Вспомним, что в зону .SU DNSSEC внедрили в октябре 2011 года, в зону .РФ — в ноябре 2012, .RU — в декабре 2012. Теперь попробуйте вспомнить хоть один домен подписанный DNSEC. Не можете? 😉 Это ожидаемо. На момент написания этой статьи из трёх регистраторов заявивших о внедрении у себя DNSSEC только один (и это Регтайм) подписал свой основной домен. К этому можно добавить, что за всё время существования DNSSEC количество вопросов от пользователей о внедрении этой технологии можно пересчитать по пальцам одного человека. Прямо скажем — не густо.

Тогда возникает логичный вопрос: Зачем внедрять? Затем, что Регтайм всегда был и остаётся пионером и первооткрывателем во многим вопросах DNS. Внедрение DNSSEC, как штатной фишки, очередной шаг. Причём не только для отечественных зон, но и для многих других.

На этом предлагаю закончить с теорией и философией. Теперь рассмотрим собственно использование DNSSEC на собственных name серверах.

Практические работы

Для того чтобы DNSSEC начал использоваться как задумано авторами нужны следующие компоненты:

— подписанная зона первого уровня (у нас есть отечественные .RU .SU и .РФ)
— домен в этой зоне (у нас есть webnames.ru)
— авторитарные DNS серверы для нашего домена (имеются)
— рисолвер (кеширующий DNS сервер)

Текущей стабильной версией Debian является Squeeze уже 6.0.7. Его и продолжим использоваться в качестве базы. В качестве собственно DNS сервера у нас bind9.

Опустим подробности установки и настройки собственно bind9. Ставится он просто:

aptitude install bind9

Компоненты для работы с DNSSEC:

aptitude install dnssec-tools libcrypt-openssl-random-perl

Все конфиги по умолчанию находятся в /etc/bind/
Здесь нас интересуют опции в named.conf.options. В них нужно добавить:

dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto;

После этого нужно перечитать конфиги или перезагрузить bind. Тут кому как нравится: rndc reconfig или /etc/init.d/bind9 restart

Для простоты внедрения будем использовать zonesigner. Это всеобъемлющая утилита, которая подписывает зону за один проход. Но есть и более сложный путь, но зачем он нужен? 😉

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

В процессе эволюции мы имеем следующую иерархию зон: auto/ru/w/e/b/n/webnames.ru. Для zonesigner была создана аналогичная параллельная ветвь: dnssec/ru/w/e/b/n/webnames.ru/

Первоначальная генерация подписанной зоны выглядит так:

mkdir -p /var/named/dnssec/ru/w/e/b/n/webnames.ru/ cd /var/named/dnssec/ru/w/e/b/n/webnames.ru/ zonesigner -genkeys -usensec3 -zone webnames.ru /var/named/auto/ru/w/e/b/n/webnames.ru

На выходе получим что-то типа:

        if zonesigner appears hung, strike keys until the program completes
        (see the "Entropy" section in the man page for details)

Generating key pair.....++++++ .........................................................................++++++ 
Generating key pair..++++++ ...++++++ 
Generating key pair....+++ .........+++ 
Verifying the zone using the following algorithms: RSASHA256.
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 1 stand-by, 0 revoked

zone signed successfully

webnames.ru:
        KSK (cur) 02110  -b 2048  02/22/13      (webnames.ru-signset-00003)
        ZSK (cur) 21834  -b 1024  02/22/13      (webnames.ru-signset-00001)
        ZSK (pub) 51069  -b 1024  02/22/13      (webnames.ru-signset-00002)

zone will expire in 4 weeks, 2 days, 0 seconds
DO NOT delete the keys until this time has passed.

А теперь убедимся, что файлов создано много:

$ls -1 dsset-webnames.ru. Kwebnames.ru.+008+02110.key Kwebnames.ru.+008+02110.private Kwebnames.ru.+008+21834.key Kwebnames.ru.+008+21834.private Kwebnames.ru.+008+51069.key Kwebnames.ru.+008+51069.private webnames.ru.krf

А рядом с файлом обычной зоны появился второй файл webnames.ru.signed и он более чем в 20 раз больше оригинала — 32669 байт против 1369. И еще 7520 байт на служебные файлы указанные выше. Т.е. мы получили в 30 раз больше информации. Правда зона webnames.ru совсем маленькая и такой прирост не сильно тяготит.

На всякий случай проверим новый файл зоны на ошибки:

$ donuts --level 8 webnames.ru.signed webnames.ru 0 errors found in webnames.ru.signed

«—level» — это уровень выдачи ошибок. Когда ошибок нет, то в нём особого смысла нет. Кстати, есть очень простой способ напороться на эти ошибки. Например, добавив NS запись со сторонним DNS сервером.
Добавим в зону запись bad NS ns1.gde-to-tam-daleko.ru и обновимся:

zonesigner -zone webnames.ru /var/named/auto/ru/w/e/b/n/webnames.ru

Обратите внимание, что править нужно всегда обычную зону, а подписанную DNSSEC нужно обновлять именно так.

Теперь проверим на ошибки:

$ donuts --level 8 webnames.ru.signed webnames.ru 
bad.webnames.ru:
  Warning:     Only 1 NS record(s) for bad.webnames.ru found, but at least
               2 are suggested/required

bad.webnames.ru:
  Error:       sub-domain bad.webnames.ru is not securely delegated.  It is
               missing a DS record.

2 errors found in webnames.ru.signed

Вот так. 🙂 Это усложнение структуры стоит учитывать в своей практике. Если вдумчиво читать, то становится понятно, что именно нужно делать. Во-первых, добавить вторую NS запись, а во-вторых, добавить DS запись для поддомена.

Но откуда же у нас эти DS берутся? Выше у нас показан файл dsset-webnames.ru. Его содержимое таково:

webnames.ru.            IN DS 2110 8 1 4F38DB26A26DDFFB0A84052472D1AF70DAA595D7
webnames.ru.            IN DS 2110 8 2 0CC3937FE64FD4BF3B8282748F93C566870F4FCD254BCF0D91DBCF50 23D6D28C

Именно эти записи нужно передать регистратору домена, чтобы он их отправил в реестр зоны. И они же нужны для того чтобы donuts перестал выдавать ошибки для NS записей.
Процедура передачи у разных регистраторов разная. На Webnames.Ru, например, в разделе «Управления доменом» «Личного кабинета» есть специальный пункт «DNSSEC» где можно включить и выключить собственно поддержку DNSSEC, а также увидеть имеющиеся DS записи и при необходимости внести новые.

Теперь вспомним о том, что все криптографические ключи имеют срок годности. Неплохо бы автоматизировать и их замену… Радует, то что есть специальный демон rollerd. В то же время печалит, то что для этого демона нет init-скрипта. Поэтому придётся его написать самостоятельно. Можно, конечно, и не писать, а обойтись колхозными методами, но это уже каждый решает сам. Еще чуть больше печалит то, что rollerd хоть и следит за ключами и заменяет их, но не может заменить их в реестре.

Сначала определимся за чем будем следить. Для этих целей есть rollinit. Он готовит для rollerd список зон за ключами которых мы собираемся следить. Давайте определимся, что список мы будем хранить в dnssec/. Соответственно, добавим туда нашу подписанную зону:

rollinit -zonefile /var/named/auto/ru/w/e/b/n/webnames.ru.signed -keyrec /var/named/dnssec/ru/w/e/b/n/webnames.ru/webnames.ru.krf -admin support@webnames.ru webnames.ru >> /var/named/dnssec/rollrec

Если кто-то читая это уже наклепал подписанных зон, то нужно их все добавить в этот же список либо следить за ключами вручную. 😉

После этого нужно запустить rollerd. Вот обещанный init-скрипт: /etc/init.d/rollerd

#!/bin/bash

### BEGIN INIT INFO
# Provides:          rollerd
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO

PATH=/bin:/usr/bin:/sbin:/usr/sbin
DESC="DNSSEC-Tools daemon to manage DNSSEC key rollover"
NAME=rollerd
DAEMON=/usr/sbin/$NAME
SCRIPTNAME=/etc/init.d/$NAME
CONF=/var/named/dnssec/rollrec
PIDFILE=/var/run/rollerd.pid

[ -x "$DAEMON" ] || exit 0
. /lib/init/vars.sh
. /lib/lsb/init-functions
[ -f $CONF ] || exit 0

start_rollerd () {
        [ -f $PIDFILE ] && return 1
        $DAEMON -rrfile $CONF -directory /etc/bind -pidfile $PIDFILE
}

stop_rollerd () {
        if [ -s $PIDFILE ]; then
                PID=`cat $PIDFILE`
                kill $PID && rm -f $PIDFILE
                sleep 3
                [ -d "/proc/$PID" ] && return 1
                return 0
        fi
        PID=`ps xa | grep -v grep | grep $DAEMON | awk '{print $1}'`
        [ -z "$PID" ] && return 0
        kill $PID
        sleep 3
        [ -d "/proc/$PID" ] && return 1
        return 0
}

case "$1" in
        start)
                log_daemon_msg "Starting $DESC" "$NAME";
                start_rollerd;
                log_end_msg $?;
                ;;
        stop|force-stop)
                log_daemon_msg "Stopping $DESC" "$NAME";
                stop_rollerd;
                log_end_msg $?;
                ;;
        restart)
                log_daemon_msg "Restarting $DESC" "$NAME";
                stop_rollerd;
                start_rollerd;
                log_end_msg $?;
                ;;
        *)
                echo "Usage: $0 ";
                exit 1;
                ;;
        esac;

exit 0;

Готовим его к запуску, автозапуску и запускаем.

chmod 755 /etc/init.d/rollerd update-rc.d rollerd defaults /etc/init.d/rollerd start

Если кто-то совсем расстроился, что полную ротацию ключей автоматизировать невозможно, то это зря. Можно, но уже при помощи почтового демона. У нас используется sendmail. Поэтому при помощи smrsh можно сделать почти всё что угодно. Делается это довольно просто. В /etc/mail/sendmail.mc добавляем следующие строки перед первым MAILER’ом:

FEATURE(`virtusertable', `hash /etc/mail/virtusertable')dnl VIRTUSER_DOMAIN_FILE(`/etc/mail/local-host-names')dnl

В /etc/mail/virtusertable добавляем:
dnssec@localhost dnssec
Этим мы создали виртуальный почтовый ящик dnssec@localhost и отправили всю входящую почту на системного юзера dnssec.

В /etc/aliases добавляем:
dnssec: "|/etc/mail/smrsh/dnssec"
Этим мы всю входящую почту юзеру dnssec отправили через пайп (т.е. в его STDIN) в скрипт /etc/mail/smrsh/dnssec

А уж в скрипте /etc/mail/smrsh/dnssec мы можем делать всё что хотим.
Стоит отметить, что скриптом это называется условно. Это может быть и бинарник.

Теперь перезапустим sendmail и все изменения вступят в силу:
/etc/init.d/sendmail restart

При этом всём не забудьте, что при использовании smrsh нужно переинициировать /var/named/dnssec/rollrec с адресом dnssec@localhost. Т.е. примерно так:

rollinit -zonefile /var/named/auto/ru/w/e/b/n/webnames.ru.signed -keyrec /var/named/dnssec/ru/w/e/b/n/webnames.ru/webnames.ru.krf -admin dnssec@localhost webnames.ru >> /var/named/dnssec/rollrec

Сам скрипт /etc/mail/smrsh/dnssec приводить не имеет смысла, поэтому ограничимся обёрткой на bash без функционала.
Само письмо выглядит примерно так:

From: root
To: dnssec@localhost
Subject: assistance needed with KSK rollover of zone webnames.ru

The zone "webnames.ru" is in the middle of KSK rollover. In order for rollover
to continue, its keyset must be transferred to its parent.

Парсить его можно, например, так:

#!/bin/bash

while read L; do
    if [ "${L:0:9}" == "Subject: " ]; then
        for W in $L ; do echo -n '' ; done
        echo "Domain $W"
    fi
done

Т.е. после разбора поля Subject по словам получим в результате имя домена (в переменной W) для которого нужно послать обновлённые DS записи в реестр.

Теперь настроим последний компонент DNSSEC — рисолвер, он же кеширующий DNS сервер. И здесь всё тоже очень просто. Если взять тот же самый bind9, то в тот же самый файл /etc/bind/named.conf.options нужно добавить те же опции и перезагрузить bind:

dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto;

/etc/init.d/bind9 restart

Теперь на рабочем компе нужно прописать в качестве DNS сервера наш рисолвер и наслаждаться DNSSEC’ом.

Вот и всё.

Опубликовано в рубрике Без рубрики | Метки: bind, dns, dnssec, rfc, домены | 1 комментарий »

Лог жизни

Записи с меткой ‘dns’

Любопытное наблюдение…

DNSSEC на практике у регистратора доменов

Историческая справка

Наши дни

Практические работы