Версия 1.1.1, 19 юни 2008
Веселин Колев, Софийски Университет "Св. Климент Охридски"
Адрес за кореспонденция: vesso AT vesselin.org
Първоизточник: http://www.vesselin.org
Лиценз на документа: CC Attribution-ShareAlike
Съдържание:
Генериране на ключ с име domain.com по алгоритъм hmac-md5 с дължина 512 бита става чрез следния команден ред:
$ dnssec-keygen -a hmac-md5 -b 512 -n HOST domain.com
Този команден ред произвежда в текущата на изпълнението му директория два файла с имена подобни на:
Kdomain.com.+157+41723.key Kdomain.com.+157+41723.private
Винаги името на файла започва с "K". След него непосредствено следва името на ключа (по горния пример това е domain.com). След това в името на файла има две числа разделени със знак "+". Първото число отразява номера на алгоритъма, който ще използва ключа. В нашия случай това е "hmac-md5" и на него съответства номер 157. Второто число е случайно генерирано и отразява уникалния номер на ключа. За примерът това е 41723.
Структурата на файла с наставка key е следната:
domain.com. IN KEY 512 3 157
8lY5dKUmEhK5EDyy/emWs90vPrj4Bo5VfR+rGwFma4NK24QseZLYhmwzKdu1UejobTAcr27GwT7xTYOc5kY5gw==
Файлът с наставка private е структуриран така:
Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: 8lY5dKUmEhK5EDyy/emWs90vPrj4Bo5VfR+rGwFma4NK24QseZLYhmwzKdu1UejobTAcr27GwT7xTYOc5kY5gw==
След като бъдат генерирани, тези два файла трябва да бъдат предпазени от публичен достъп. Първата стъпка за това е да им бъдат зададени съответните за това права за достъп спрямо локалната файлова система. Тези права трябва да се зададат така, че да позволяват четене на файловете само от страна на техния собственик. Задаването им може да стане с команден ред от вида:
$ chmod 600 Kdomain.com.+157+41723.*
Ако файловете се съхраняват на външен носител, то те трябва да бъдат задължително в криптиран вид.
Целта на създаването на този файл е да може демонът named да чете ключа, доколкото при динамично управление на зоналния файл правата за писане в него се дават на база валиден ключ. BIND9 използва специален файлов формат за съхранение на ключове. Той е структуран по следния начин (името на ключа, алгоритъма и стойността на ключа са на база примера от параграф 1):
key "domain.com" {
algorithm hmac-md5;
secret
"8lY5dKUmEhK5EDyy/emWs90vPrj4Bo5VfR+rGwFma4NK24QseZLYhmwzKdu1UejobTAcr27GwT7xTYOc5kY5gw==";
};
Така изграденият файл се поставя в директория, от която да може да бъде четен от демона named (следователно читаем от потребителя, с чиито права се стартира демона). Този файл не трябва да бъде читеам от други потребители на системата. Обикновено се постъпва така. Ако описаната по-горе структура се намира във файла /etc/named/keys/domain.com.key, то правата върху този файл се установяват в команден ред чрез следните команди:
$ chmod 640 /etc/named/keys/domain.com.key $ chown root:named /etc/named/keys/domain.com.key
Разбира се в този пример предполагаме, че потребителят, който стартира демона named, носи името named. За конкретната система това може да бъде друг потребител и втория команден ред от по-горе трябва да отчете това.
named.confЗа да може BIND9 да използва ключа описан в параграф 2, този ключ трябва да се намира в конфигурационния файла на демона named. Конфигурационният файл обикновено носи името named.conf. Лоша практика е ключа да се поставя директно в named.conf. Причината е, че може да се наложи този файл да е читаем от много потребители и тогава ключа вече няма да се пази в тайна. За да се не получават подобни проблеми, трябва някъде в началото на файла named.conf да се постави декларацията include, чрез която ключа да се чете от демона от външен файл. Например, ако ключа се намира в /etc/named/keys/domain.com.key, то записа в named.conf ще е от вида:
include "/etc/named/keys/domain.com.key";
При конкретната реализация обърнете внимание на частта в параграф 2, която указва на собствеността и правата върху файла с ключа.
named.confВсяка зона в named.conf, която има атрибута "allow-update" е динамично управляема. След "allow-update" се поставя обикновено списък с IP адреси и/или ключове (последните се обявяват чрез имената си). По-добре организираната от гледна точка на сигурността схема предолага използването на списък с имена на ключове, а не списък с IP адреси. Причината е, че IP измамата е лесно осъществима и при нейното извършване може да се промени злоумишлено зоналния файл. Ето един пример за описание на динамично управляема зона в named.conf:
zone "domain.com" {
type master;
file "domain.com";
allow-update { key "domain.com"; };
notify yes;
also-notify { 10.1.2.4; };
allow-query { any; };
allow-transfer { 192.168.100.1; 192.168.1.2; 10.1.2.4; };
};
В показаният пример се дефинира динамично управляема зона domain.com. Управлението на записите в нея се осъществява от страна на клиента с помощта на ключа с име domain.com (този ключ трябва да се намира във файла named.conf, както е показано в параграф 3). Типът на зоната е master. Чрез указването на "notify yes" се указва на named след всяка извършена промяна (касаеща записите в зоналния файла), да изпрати сигнал за синхронизирането й към всички сървъри за имена, които са описани като NS ресурсни записи в зоната domain.com (изпълняващи ролята на подчинени, slave). Чрез also-notify се уведомяват и други сървъри за имена (които не са описани чрез NS ресурсни записи в зоната) да синхронизират промените (в горния случай това е сървър с IP адрес 10.1.2.4). Чрез "allow-query { any; };" се разрешава запитване към зоната от страна на всеки клиент, а чрез allow-transfer се позволява на клиентите упоменати в последващия в списък чрез IP адреса си, да трансферират зоната. В този списък трябва да влизат всички сървъри за имена, упоменати като такива в зоната чрез NS ресурсни записи и тези, които са в списъка с адреси след also-notify. Причината е, че е безполезно да се изпраща "notify" съобщение без на получателя да се разреши изтегляне на зоната.
По конвенция и без допълнителни настройки, named чете и записва зоналните файлове в директория по подразбиране, която зависи от параметрите подадени при компилация. Това не е добра практика. За това в секцията options на конфигурационния за named файл named.conf, се указва директория чрез следната инструкция:
options {
...
directory "/var/named";
...
};
В тази директория, или нейни поддиректории, демонът named ще чете, записва/променя зонални файлове. В случаят на динамично управляемите зони има една малка особеност. Тя се изразява в създаването на допълнителен журнален файл. Къде се намира той и каква е неговата роля? Ако се следва примера за описание на динамично управляема зона от параграф 5 и иписанието за директория на named от по-горе, зоната domain.com се намира във файла /var/named/domain.com. Тъй като тя е обявена за динамично управляема, то за нея ще бъде създаден съотвения журнален файл /var/named/domain.com.jnl. Журналният файл служи за съхранение на текущите промени в зоната, които са извършени по механизмите за динамично управление на записите и се създава от демона named при първи прочит на атрибутите за динамично управляема зона. Следователно потребителят, с чиито права се изпълняват процесите на named, трябва да има права за писане в директорията /var/named/, а също така и зоналния файл, и неговият журнал, трябва да са писаеми и читаеми от страна на named.
Внимание! По никакъв повод не бива да се изтрива журналния файла на зоната, тъй като така могат да бъдат загубни последните промени. Също така не бива да се прави каквато и да е редакция на зоналния файл при наличието на журнален файл.
След като промените в зоната бъдат подадени от страна на клиента към демона named, последния ги записва в журналния файл и след период от време (по подразбиране 15 минути), ги превхвърля от журналния в зоналния файл. Именно за това зоналният файл трябва да е писаем за потребителя, с чиито права се стартира демона named. В противен случай промените няма да могат да бъдат поставени в зоналния файл.
Все пак някога може да се наложи да се редактира зоналния файл. Как да бъде извършена редакцията на зоналния файл в условията на динамичен режим на управление на зоната? Отговорът е "като временно излезем от режим на динамично управление". Това става чрез инструмента rndc по следния начин:
$ rndc freeze domain.com
В горния команден ред става "замразяване" на зоната на домейна domain.com. Това означава, че промените от журналния файл се записват в зоналния и след това журналния файл се премахва. Сега вече зоналният файл може да се редактира ръчно с текстови редактор.
За да се приведе зоната отново в режим на динамично управление, тя трябва да се "размрази". Това става след като редакциите по зоналния файл са привършили и той е затворен. "Размразяването" се извършва с инструмента rndc по следния начин:
$ rndc unfreeze domain.com
Така става "размразяване" на зоната domain.com и named отново включва тази зона в режим на динамично управление и създава прилежащия към зоналния файл журнален файл.
Вписването на събития следва схемата, използвана на ISC BIND9. Категорията на описване на събитията по динамичното управление на зони се нарича "dynamic". Една примерна конфигурация за описание в named.conf би изглеждала по следния начин:
logging {
channel DYN_log{
file "/var/log/named/dynamic.log" versions 3 size 10m;
severity info;
# only send priority info and higher
print-severity yes;
print-time yes;
};
category update { DYN_log ; };
};
При това описание, събитията по динамичното управление на зоните, ще се отразяват във файла /var/log/named/dynamic.log. За повече информация относно подробността на описанието, може да се използва информацията в "BIND 9 Administrator Reference Manual" (идваща с пакета BIND9).
Версия 1.1: [tar.gz] [електронен подпис върху архива]
Публикувана на: 14 октомври 2007г.
Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис][TimeStamp]