Версия 1.1.1, 19 юни 2008
Веселин Колев, Софийски Университет "Св. Климент Охридски"
Адрес за кореспонденция: vesso AT vesselin.org
Първоизточник: http://www.vesselin.org
Лиценз на документа: CC Attribution-ShareAlike
Съдържание:
TSIG е метод за извършване и проверка на електронен подпис върху DNS заявки и отговорите им с помощта на криптосистема със секретен ключ. Методът е обект на описание в RFC2845.
В основата на метода е споделен секретен ключ между двете страни - участнички в генерирането на DNS заявката (от страна на клиента) и нейното изпълнение и връщане на отговора (от страна на сървъра). Споделеният секретен ключ може да има (за пректическите реализации на метода към настоящия момент) дължина от 512 бита. Този ключ се използва за подписване на заявките в рамките на алгоритъм известен като HMAC. Към настоящият момент се използва HMAC, който използва хеш алгоритъма MD5. Затова работният HMAC алгоритъм, който към момента се използва в TSIG се нарича HMAC-MD5.
В рамките на TSIG информацията се обменя в открит текст, но заедно с този открит текст, се подава (като прибавена порция информация) и електронния му подпис, извършен чрез HMAC-MD5. Т.е. информацията и електронния подпис "пътуват" заедно в Интернет.
Електронното подписване със споделен секретен ключ по алгоритъм HMAC-MD5 може да се обясни опростено така. Имаме блок информация, ключ и хеш алгоритъм MD5. По определена схема става строго регламентирано (стандартизирано) съединяване на блока информация и ключа (в някои междинни стъпки на съединяването се прилага MD5). Накрая чрез MD5 се пресмята окончателния хеш на преди това смесения и междинно хеширан блок. Шестнадесетичното число - изход от последното прилагане на MD5 върху смесения блок, е електронния подпис върху изходния блок с информация. Това число е електронен подпис, защото носи идентичност - само този, който притежава секретния ключ може да получи това число от изходния блок информация чрез прилагането на HMAC-MD5 върху него. На същият принцип почива проверката на електронния подпис. Получателят също има копие от секртетния ключ. След като получи блока с информация и неговия подпис, той извършва със своето копие на секретния ключ всички операции до получаването на крайното шестнадесетично число и го сравнява с полученото. Ако двете числа (изчисленото локално и полученото от изпращащия блока информация) са равни, то електронния подпис е проверен и получената информацията е автентична.
Освен проверка на източника на информация, TSIG може да служи за проверка за наличието на "прозрачни" DNS сървъри. Някои доставчици на интернет свързаност насочват всички заявки на клиентите си, които имат за цел порт 53/udp, към свой сървър за имена. Подобно насточване веднага проваля TSIG обмена и е индикация за наличието на такава "прозрачна" схема за отклонение на заявките.
Една от слабите страни на TSIG е липсата (засега) на стандартизация за работа с криптоалгоритми с публичен ключ, които да не налагат споделянето на секретен ключ, което е доста ограничаващо.
За да се реализират описаните в документацията техники се предполага, че върху сървърската и клиентската системи има инсталиран BIND9 (интернет страница на проекта: http://www.isc.org/bind) и NTP (http://www.ntp.org/). В Linux дистрибуциите Red Hat Enterprise Linux и Fedora, BIND9 се инсталира като RPM пакет с името bind (с допълнителен пакет bind-chroot за реализиране на chroot среда), а NTP като пакет с име ntp. За да се провери дали необходимите пакети са инсталирани в системата, може да се изпълни следния команден ред:
$ rpm -q bind bind-chroot ntp
Ако след изпълнението на този команден ред се получи отговор от вида
bind-9.2.4-16.EL4 bind-chroot-9.2.4-16.EL4 ntp-4.2.0.a.20040617-4.EL4.1
то и трите пакета са инсталирани в системата. Ако не бъде получен отговор, който да потвърждава наличието на всичките или дори само на един от пакетите в системата, то липсващите пакети трябва да се инсталират. Инсталирането може да се извърши по два начина:
чрез инструмента up2date
Използването на инструмента up2date е по-характерно за Red Hat Enterprise Linux, но е наличен и в неговите производни (като CentOS). Инсталирането на липсващите пакети се извършва по схемата:
# up2date bind bind-chroot ntp
чрез инструмента yum
Използването на инструмента yum е характерно за дистрибуцията Fedora Core или производните на Red Hat Enterprise Linux (като CentOS). Инсталирането на липсващите пакети се извършва по схемата:
# yum install bind bind-chroot ntp
Посочените по-горе два командни реда инсталират само липсващия пакет и актуализират вече инсталираните пакети (ако актуализации за тях са налични и достъпни)
В рамките на добрата практика по поддържане на високо ниво на сигурност и прозводителност, пакетите bind, bind-chroot и ntp трябва да се актуализират тогава, когато в хранилището "updates" на дистрибуцията има нови актуализации. В Linux дистрибуциите Red Hat Entperprise Linux и Fedora Core, има два начина за актуализация:
чрез инструмента up2date
Използването на инструмента up2date е по-характерно за Red Hat Enterprise Linux, но е наличен и в неговите производни (като CentOS). Актуализацията на пакетите bind, bind-chroot и ntp се извършва в команден ред така:
# up2date bind bind-chroot ntp
чрез инструмента yum
Използването на инструмента yum е характерно за дистрибуцията Fedora Core или производните на Red Hat Enterprise Linux (като CentOS). Актуализацията на пакетите bind, bind-chroot и ntp се извършва в команден ред така:
# yum update bind bind-chroot ntp
Генерирането на секретен ключ за нуждите на алгоритъма за електронно подписване и проверка на електронния подпис (с участието на HMAC), може да се извърши чрез инструмента rndc-confgen. Той е в състава на пакета bind. Ето примерен команден ред за генерирането на ключ с дължина 512 бита и име "warrior", който след генерирането бива запазен във файла hmac-key.asc (в локалната за изпълнение на командния ред директория):
$ umask 077 && /usr/sbin/rndc-confgen -r /dev/urandom -a -b 512 -c hmac-key.asc -k warrior
Извикването на umask с аргумент 077 в началото, има за цел да зададе права за четене на файла hmac-key.asc само от страна на собственика му (този, който е изпълнил командния ред). Целта е да се избегне възможността друг потребител на локалната система (освен този, който има права на супер потребител, разбира се), да може да копира ключа. Задаването на тези права за достъп става още преди съдържанието да е поставено във файла.
Съдържанието на hmac-key.asc има следната структура
key "warrior" {
algorithm hmac-md5;
secret
"A12xk1dLj0D4BqSe2sqkwvkFFyOAuYI+y6EIbIBocNfwttPHkyBAxGbsfa0eBotpWr4H5N2KdxIG6lAQlSUNmA==";
};
и то не трябва да се променя по никакъв повод!
Генерираният секретен ключ трябва да бъде копиран върху двете системи, които ще участват в подписването и проверката на заявките. За целта трябва да се използва сигурен канал за предаването на ключа. Този канал може да се реализира чрез комуникации, които са базирани на криптографския протокол SSL, чрез транспортиране на ключа криптиран във файл, чрез изпращане на криптирания ключ чрез криптирано електронно писмо и др.
Доколкото при използването на TSIG, синхронизацията на частовника на локалната система е криптична, то особено внимание трябва да се отдели на настройката на демона ntpd (от RPM пакета ntp). Това важи както за сървъра за имена, който ще изпълнява рекурсивните заявки, така и за клиентския сървър за имена, който ще извършва само изпращане и получаване на подписани заявки. Доколкото тази документация няма за обект анализ на настройките на ntpd, тук само е посочена една примерна конфигурация, която може да бъде приета за добра практика. Местонахожденията на съответните файлове са такива, каквито са зададени в пакетната система.
/etc/ntp.conf
# Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. restrict default nomodify notrap noquery # Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1 # -- CLIENT NETWORK ------- # Permit systems on this network to synchronize with this # time service. Do not permit those systems to modify the # configuration of this service. Also, do not use those # systems as peers for synchronization. # restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap # --- OUR TIMESERVERS ----- server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org # --- NTP MULTICASTCLIENT --- #multicastclient # listen on default 224.0.1.1 # restrict 224.0.1.1 mask 255.255.255.255 nomodify notrap # restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap # --- GENERAL CONFIGURATION --- # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 # # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /var/lib/ntp/drift broadcastdelay 0.008 # # Keys file. If you want to diddle your server at run time, make a # keys file (mode 600 for sure) and define the key number to be # used for making requests. # # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. Note also that # ntpd is started with a -A flag, disabling authentication, that # will have to be removed as well. # keys /etc/ntp/keys
/etc/ntp/step-tickers
129.6.15.28 129.6.15.29 193.67.79.202 193.79.237.14
Файлът /etc/ntp/step-tickers извършва първоначалната синхронизация (груба синхронизация) по време, за да може след това алгоритъма на протокола NTP да извърши финната настройка (указана във файла /etc/ntp.conf). Грубата синхронизация е достатъчна за да сработи алгоритъма за TSIG обмяна на подписани DNS заявки и отговорите им. Именно поради това, че преди да има синхронизация по време не може да има успешен TSIG обмен (а с това и обслужване на DNS заявките), сървърите за имена във файла /etc/ntp/step-tickers са указани по адрес, а не по име (както е в /etc/ntp.conf). Този списък не е стриктен и може да подлежи на промяна. Списък със сървъри за време може да бъде намерен на адрес:
http://ntp.isc.org/bin/view/Servers/StratumTwoTimeServers
След като изборът на сървъри за време по този списък бъде направен, техните имена се транслират до IP адреси и се записват (всеки адрес на нов ред) във файла /etc/ntp/step-tickers.
Указването на стартиране на услугата ntpd при старт на системата и ръчното стартиране на услугата следват познатата за Red Hat Enterprise Linux и Fedora Core схема:
# chkconfig ntpd on # service ntpd start
Файлът със секретния ключ (за примера се приема, че се намира във файла /home/user/hmac-key.asc) се копира в директория /var/named/chroot/etc и му се указва собственост и права за достъп:
# cd /var/named/chroot/etc # cp /home/user/hmac-key.asc # chown root:named && chmod 640 hmac-key.asc
След това във файла /var/named/chroot/etc/named.conf се прави описание на включване за прочит от страна на демона named, на файла със секретния ключ. За целта се използва конфигурационен елемент "include" по следния начин:
include "/etc/hmac-key.asc";
Нужно е да се отбележи, че пътят до файла с ключа се отчита спрямо "chroot" директорията (която от гледна точка на заключения в нея демон, премества "/" в себе си). Именно затова файлът се указва като /etc/hmac-key.asc, а не като /var/named/chroot/etc/hmac-key.asc.
След това се прави деклариране на конфигурационен елемент "server" със съдържание подобно на следното:
server 172.16.2.1 {
key warrior;
};
Целта на този елемент е да укаже IP адреса на сървъра за имена (задава се ведната след обявяването на елемента), до който подписаните заявки ще бъдат изпращани и от който ще бъдат очаквани подписани отговори, и името на ключа с който ще се осъществява подписването и проверката на електронния подпис (в примера горе е указан ключ с име "warrior".)
След това обявеният с конфигурационния елемент "server" сървър за имена, се указва в конфигурационната подструктура "forwarders" на конфигурационния елемент "options" във файла /var/named/chroot/etc/named.conf
options {
...
forward only;
forwarders { 172.16.2.1; };
...
};
Ако за комуникация със сървъра за имена се използва нестандартен порт (различен от 53/udp и 53/tcp), то той се указва при описанието на сървъра в подструктурата на "forwarders":
options {
...
forward only;
forwarders { 172.16.2.1 port 5353; };
...
};
Тук за примера са указани за използване портове 5353/udp и 5353/tcp.
След като промените във файла /var/named/chroot/etc/named.conf бъдат извършени, трябва да се стартира проверка на синтаксиса на указаните в него конфигурационни елементи. Това става чрез инструмента named-checkconfig:
# named-checkconfig -t /var/named/chroot
Ако при изпълнението на този команден ред не бъде изведено съобщение за грешка, конфигурацията може да бъде въведена в сила. Ако вече има стартиран демон named и тази конфигурация касае именно него, то въвеждането й в сила може да стане така:
# rndc reconfig
Ако в системата няма работещ в момента демон named, може да се стартира такъв, с прочит на новата конфигурация, чрез стандартните за това похвати в Red Hat Enterprise Linux и Fedora Core:
# service named start
След това се настройва библиотеката на резолвера, за използването на локалния демон named. Това става чрез запис във файла /etc/resolv.conf:
nameserver 127.0.0.1
Ако този сървър (който топологично, от гледна точка на TSIG комуникацията, е клиент), има ролята на кеширащ за някаква мрежа от работни станции и сървъри, трябва да се направят съответните за това настройки във файла /var/named/chroot/etc/named.conf, за да може услугата да бъде използвана от тях.
И тук, както и при настройката на клиентската част, първата и основна задача е да се включи съдържанието на файла със споделения секретен ключ, чрез който ще става подписването на съобщенията, и проверката на електронния подпис върху тях.
Файлът със секретния ключ (за примера се приема, че се намира във файла /home/user/hmac-key.asc) се копира в директория /var/named/chroot/etc/tsig-keys и му се указва собственост и права за достъп:
# cd /var/named/chroot/etc/tsig-keys # cp /home/user/hmac-key.asc . # chown root:named && chmod 640 hmac-key.asc
След това във файла /var/named/chroot/etc/named.conf се прави описание на включване за прочит от страна на демона named, на файла със секретния ключ. За целта се използва конфигурационен елемент "include" по следния начин:
include "/etc/tsig-keys/hmac-key.asc";
Следват настройките на демона named, който в случая игра ролята на сървърската страна - тази, която изпълнява рекурсивните заявки на клиента. Основната задача тук е как да се разреши влизане в рекурсия за даден заявител, без оглед на това от какъв IP адрес той излъчва заявката си. Най-удобният за това начин е използването на "acl" конфигурационен елемент във файла /var/named/chroot/etc/named.conf, чрез който се указва името на ключа, който ще се използва:
acl tsig-clients {
key warrior;
};
В този пример е показано как ключа с име "warrior" става част от конфигурационния елемент за контрол на достъп с име "tsig-clients". Възможно е в един конфигурационен елемент, представляващ списък за контрол на достъпа, да се съдържат не само имена на ключове, но и IP адреси, а също така и да включва в себе си и други имена на списъци за контрол на достъпа.
След като горната дефиниция бъде направена, следва указване на името на списъка за контрол на достъпа в конфигурационните поделементи "allow-query" и "allow-recursion" на елемента "options":
options {
...
allow-query { tsig-clients; };
allow-recursion { tsig-clients; };
...
};
След като промените във файла /var/named/chroot/etc/named.conf бъдат извършени, трябва да се стартира проверка на синтаксиса на указаните в него конфигурационни елементи. Това става чрез инструмента named-checkconfig:
# named-checkconfig -t /var/named/chroot
Ако при изпълнението на този команден ред не бъде изведено съобщение за грешка, конфигурацията може да бъде въведена в сила. Ако вече има стартиран демон named и тази конфигурация касае именно него, то въвеждането й в сила може да стане така:
# rndc reconfig
Ако в системата няма работещ в момента демон named, може да се стартира такъв, с прочит на новата конфигурация, чрез стандартните за това похвати в Red Hat Enterprise Linux и Fedora Core:
# service named start
Версия 1.1: [tar.gz] [електронен подпис върху архива]
Публикувана на: 14 октомври 2007г.
Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис] [TimeStamp: заявка|удостоверение]