Портал > Документация > Инсталиране и настройка на BIND-базиран DNS клиент, поддържащ TSIG, под CentOS 7 и Scientific Linux 7
Инсталиране и настройка на BIND-базиран DNS клиент, поддържащ TSIG, под CentOS 7 и Scientific Linux 7
Съдържание:
- Предварителна информация
- Инсталиране на BIND софтуера
- Конфигуриране на BIND
- Установяване на TSIG комуникация между локалния BIND и DNS сървъра
- Проверка на TSIG комуникацията с dig
- Прочит на журналните ("log") файлове на BIND
- Използване на TSIG комуникацията от локалните приложения на сървъра
1. Предварителна информация
TSIG комуникацията е цифрово подписан обмен на DNS заявки и техните отговори. При TSIG DNS клиентът изпраща към BIND сървъра заявка, която подписва цифрово с ключ, копие от кой има в конфигурацията на BIND. Когато демонът на BIND (изпълнимия файл named) получи TSIG заявката, той поверява с какво име на ключа е извършен подписа и търси в конфигурацията си записи за този ключ. След като намери копие от ключа, named го използва за да провери валидността на цифровия подпис върху заявката. Ако той е валиден, named проверява и дали времето, по което е поставен подписа (това време е част от подписа) не е твърде назад в миналото. В случай, че и тази проверка даде положителен резултат, заявката се обслужва, нейния отговор се подписва цифрово със същия TSIG ключ и резултата се изпраща обратно до клиента. От своя страна, клиентът извърша същата проверка при себе си и решава дали да приеме отговора.
Защо е нужно да се използват цифрово подписани заявки в HPC инфраструктура, която по дефиниция е затворена? Наистина, в повечето случаи HPC инфраструктурата е мрежово изолирана и трафика между изчислителните сървъри в нея не се транзитира през публична среда за пренос (MAN или Интернет). В някои случаи обаче е възможно да възникне ситуация, при която сървър (или комутатор) в инфраструктурата да бъде "превзет" и да се използва за IP измама. При успешна IP измама, може да бъде фалшифицирана DNS информацията, което в повечето случаи е катастрофално! Така, че колкото и тромаво да изглежда използването на TSIG в HPC инфраструктура, това е много ефективна застраховка срещу фалшифициране на DNS информацията.
Преди да започнете да изпълнявате инструкциите дадени по-долу, трябва да се убедите, че локалния часовник на системата, върху която ще работи демона на BIND, е сверен с универсалното координатно време. За целта, трябва да инсталирате, конфигурирате и стартирате локално NTP клиент, както е показано в "Инсталиране и настройка на NTP клиент под CentOS 7 и Scientific Linux 7" (освен ако тази система не е тази, върху която е NTP сървъра за поддръжка на заявките на участниците в HPC инфраструктурата).
2. Инсталиране на BIND софтуера
Инсталирайте нужните пакети, използвайки yum (ще са ви нужни права на super user, sudo):
# yum install bind-chroot bind-utils
Все още не стартирайте услугата named-chroot. Прочетете вниманително следващата част на документа, за да създадете първоначалната конфигурация и да стартирате BIND на нейна основа.
3. Конфигуриране на BIND
Копирайте шаблоните на конфигурацията, използвайки wget, създайте съответните директории и установете върху тях съответната собственост и права за достъп:
# cd /var/named/chroot/etc
# wget https://unite.uni-sofia.bg/docs/named.conf.client
# wget https://unite.uni-sofia.bg/docs/logging.conf
# wget https://unite.uni-sofia.bg/docs/servers.conf
# mkdir pki/tsig-keys
# chown root:named pki/tsig-keys
# chmod 750 pki/tsig-keys
# mv named.conf.client named.conf
# mkdir /var/named/chroot/var/log/named
# chown named:named /var/named/chroot/var/log/named
# chmod 750 /var/named/chroot/var/log/named
# chcon -t var_log_t /var/named/chroot/var/log/named
Отворете файла /var/named/chroot/etc/named.conf с текстов редактор и редактирайте там (ако това се налага), IP адресите, които са описани след forwarders:
forwarders { fccc:67c:20d0:ffff::100; };
Заменете IP адреса fccc:67c:20d0:ffff::100 с този на BIND DNS сървъра за системата, към който ще се препращат заявките. След това, създайте ключ, с помощта на когото инструмента rndc ще подава цифрово подписани команди към демона на BIND (изпълнимия файл named):
# rndc-confgen -a -b 512 -A hmac-sha256 -k "rndc" -c /etc/rndc.key -r /dev/urandom
# chown root:named /etc/rndc.key
# chmod 640 /etc/rndc.key
Направете така, че услугата да се стартира при зареждане на системата и след това рестартирайте демона (ако не е бил стартиран преди това, рестартирането е еквивалентно на стартирането му):
# systemctl enable named-chroot
# systemct restart named-chroot
За да проверите дали инструмента за управление на BIND rndc успешно комуникира с демона named, изпълнете:
# rndc status
При успешна комуникация (т.е. named работи и ключа генериран по-горе е усешно прочетен от named и rndc), ще видите съобщение от вида:
version: 9.9.4-RedHat-9.9.4-73.el7_6
CPUs found: 1
worker threads: 1
UDP listeners per interface: 1
number of zones: 98
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
4. Установяване на TSIG комуникация между локалния BIND и DNS сървъра
Пристъпете към изпълнение на процедурите, описани долу, само и единствено, ако успешно сте изпълнили тези, дадени в предишната секция на този документ.
Ключът за извършване на TSIG подписването ще получите от администратора на BIND-базирания DNS сървър, който обслужва HPC инфраструктурата. След като го получите, трябва да го запазите във файл, който се намира в /var/named/chroot/etc/pki/tsig-keys. За примера по-долу, файла с ключа е с име node001.unite.uni-sofia.bg.key. Той трябва да се копира в директория /var/named/chroot/etc/pki/tsig-keys и там да установете съответната собственост и права за достъп до съдържанието му:
# cp /path/to/node001.unite.uni-sofia.bg.key /var/named/chroot/etc/pki/tsig-keys
# chown root:named /var/named/chroot/etc/pki/tsig-keys/node001.unite.uni-sofia.bg.key
# chmod 640 /var/named/chroot/etc/pki/tsig-keys/node001.unite.uni-sofia.bg.key
След това, отворете файла /var/named/chroot/etc/servers.conf и добавете там, на нов ред, "include" декларация, която сочи към файла с ключа:
include "/etc/pki/tsig-keys/node001.unite.uni-sofia.bg.key";
Забележете, че вместо истинският път до файла:
/var/named/chroot/etc/pki/tsig-keys/node001.unite.uni-sofia.bg.key
вие описвате:
/etc/pki/tsig-keys/node001.unite.uni-sofia.bg.key
Защо се налага да изпуснете /var/named/chroot в началото на пътя? Защото дискутираната тук схема на стартиране и поддръжка на демона на BIND (изпълнимия файл named), се базира на технология, наречена "chroot" ("Change Root"). При нея, демонът named се стартира по такъв начин, че за него кореновата директория "/" е всъщност /var/named/chroot, но той не вижда това. С други думи, при стартирането си, той бива "заключен" в директория /var/named/chroot и неговите процеси не могат (теоретично) да създават, четат или изтриват файлове извън нея.
След това, в същия този файл /var/named/chroot/etc/servers.conf, обект на редакция по-горе, трябва да декларирате (на база IP адрес) BIND-базирания DNS сървър, с който ще осъществявате TSIG подписана комуникация (обикновено, това е сървъра, посочен в списъка след forwarders в /var/named/chroot/etc/named.conf):
server fccc:67c:20d0:ffff::100 {
keys { "node001.unite.uni-sofia.bg" ; };
};
Запазете промените във файла /var/named/chroot/etc/servers.conf и го затворете. След това проверете коректността на стартовата конфигурация на BIND, изпълнявайки:
# named-checkconf -t /var/named/chroot/
Ако при изпълнението не възникне съобщение за грешка, накарайте демона named да прочете променената конфигурация (в която е включен новия ключ):
# rndc reconfig
5. Проверка на TSIG комуникацията с dig
Може да използвате инструмента dig (той е част от вече инсталирания пакет bind-utils) за да направите проверка дали TSIG комуникацията, която следва да се осъществява на база на конфигурацията, се осъществява без проблеми:
# dig -k /var/named/chroot/etc/pki/tsig-keys/node001.unite.uni-sofia.bg.key @fccc:67c:20d0:ffff::100 -t a www.uni-sofia.bg
Резултатът, който ще получите (при успешна TSIG комуникация), ще има следния вид:
; <<>> DiG 9.9.4-RedHat-9.9.4-73.el7_6 <<>> -k /var/named/chroot/etc/pki/tsig-keys/node001.unite.uni-sofia.bg.key @192.168.122.100 -t a www.uni-sofia.bg
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30590
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.uni-sofia.bg. IN A
;; ANSWER SECTION:
www.uni-sofia.bg. 86398 IN A 62.44.96.22
;; AUTHORITY SECTION:
uni-sofia.bg. 86398 IN NS ns2.uni-sofia.bg.
uni-sofia.bg. 86398 IN NS ns1.uni-sofia.bg.
uni-sofia.bg. 86398 IN NS ns.digsys.bg.
;; ADDITIONAL SECTION:
ns.digsys.bg. 345596 IN A 192.92.129.1
ns.digsys.bg. 345596 IN AAAA 2a02:6a80::192:92:129:1
ns1.uni-sofia.bg. 345596 IN A 62.44.96.140
ns1.uni-sofia.bg. 345596 IN AAAA 2001:67c:20d0:ff::140
ns2.uni-sofia.bg. 345596 IN A 62.44.96.141
ns2.uni-sofia.bg. 345596 IN AAAA 2001:67c:20d0:ff::141
;; TSIG PSEUDOSECTION:
node001.unite.uni-sofia.bg. 0 ANY TSIG hmac-sha256. 1554350946 300 32 am/XF7iefxSdtV1yZ7Ylm/wmTpvaGRd7Pp/HAastCEE= 30590 NOERROR 0
;; Query time: 2 msec
;; SERVER: 192.168.122.100#53(192.168.122.100)
;; WHEN: Mon Mar 04 07:09:06 EEST 2019
;; MSG SIZE rcvd: 352
Информацията, която е индикатор, че TSIG комуникацията е успешна, се намира в редовете под "Got answer" и ";; TSIG PSEUDOSECTION:". Ако в реда под "Got answer" виждате "NOERROR", то комуникацията е протекла успешно. Същият индикатор "NOERROR" ще виждате и под ";; TSIG PSEUDOSECTION:". Забележете, че този ред под ";; TSIG PSEUDOSECTION:" съдържа и информация за TSIG подписването.
В следващата стъпка, трябва да проверите дали локално работещия BIND сървър (този, който сте настроили според инструкциите по-горе), препраща DNS заявките към BIND-базирания сървър на HPC инфраструктурата, използвайки TSIG. Отново използвайте dig, но този път не указвайте ключ и изпратете заявката към локалния IPv6 адрес:
$ dig @::1 -t a www.uni-sofia.bg
Ако TSIG функционира нормално, ще получите отговор, в който ще има информацията, която сте заявили да получите, но няма да виждате информация за TSIG:
; <<>> DiG 9.9.4-RedHat-9.9.4-73.el7_6 <<>> @::1 -t a www.uni-sofia.bg
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.uni-sofia.bg. IN A
;; ANSWER SECTION:
www.uni-sofia.bg. 16573 IN A 62.44.96.22
;; AUTHORITY SECTION:
uni-sofia.bg. 16573 IN NS ns2.uni-sofia.bg.
uni-sofia.bg. 16573 IN NS ns.digsys.bg.
uni-sofia.bg. 16573 IN NS ns1.uni-sofia.bg.
;; ADDITIONAL SECTION:
ns1.uni-sofia.bg. 275772 IN A 62.44.96.140
ns1.uni-sofia.bg. 275772 IN AAAA 2001:67c:20d0:ff::140
ns.digsys.bg. 275772 IN A 192.92.129.1
ns.digsys.bg. 275772 IN AAAA 2a02:6a80::192:92:129:1
ns2.uni-sofia.bg. 275772 IN A 62.44.96.141
ns2.uni-sofia.bg. 275772 IN AAAA 2001:67c:20d0:ff::141
;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Mar 04 02:57:10 EEST 2019
;; MSG SIZE rcvd: 253
Прочетете следващата част от този документ, в която ще разберете как да получите информация за заявките, които са изпратени към локалния BIND и дали те са изпълнени или не.
6. Прочит на журналните ("log") файлове на BIND
Ако е извършена конфигурацията, която е предложена по-горе в този документ, журналните ("log") файлове на BIND ще се намират в директория /var/named/chroot/var/log/named. Тези от тях, чиито съдържание ще ви е нужно най-често за анализи на проблеми или клиентска активност, са: default.log, network.log, queries.log, security.log.
Ако желаете да проверите дали TSIG комуникацията между локалния BIND сървър и този, който обслужва HPC инфраструктурата (описан във "forwarers" в /var/named/chroot/etc/named.conf) е успешна, може да проверите съдържанието на файла /var/named/chroot/var/log/named/queries.log. Записите там за успешно изпълнени заявки, ще изглеждат приблизително така:
05-Apr-2019 03:05:25.387 queries: client ::1#39608 (www.redhat.com): query: www.redhat.com IN A +E (::1)
05-Apr-2019 03:05:30.388 queries: client ::1#39608 (www.redhat.com): query: www.redhat.com IN A +E (::1)
Забележете, че тези записи не съдържат информация за TSIG подписването! Подобни записи могат да бъдат намерени на сървъра, към който завките се насочват!
В случай, че DNS услугата не работи по вина на проблеми с TSIG, трябва да изискате от администратора на DNS сървъра повече информация за проблема, защото тази информация ще се намира в журналните ("log") файлове при него.
7. Използване на TSIG комуникацията от локалните приложения на сървъра
За да могат приложенията да използват локалния BIND, настроен съгласно инструкциите дадени по-горе, трябва да направите съответни записи във файла /etc/resolv.conf. Не редактирайте файла директно, а използвайте съответния механизъм за настройката им, в зависимост от ситуацията:
-
ако използвате NetworkManager за управление на мрежовите интерфейси (по подразбиране):
Настройките, описани по-долу, трябва да направите за този интерфейс, през който ще преминава комуникацията до DNS сървъра, към който TSIG заявките се изпращат. Трябва да станете super user (станете такъв чрез sudo) и да изведете списъка с мрежови интерфейси, управлявани от NetworkManager:
# nmcli c s
Ще получите отговор подобен на следния:
NAME UUID TYPE DEVICE
ens3 f88c0124-0b3a-422f-8123-1d42cb1a2687 ethernet ens3
Използвайте UUID идентификатор на интерфейса, за да влезете в режим на редакция на интерфейса:
# nmcli c e f88c0124-0b3a-422f-8123-1d42cb1a2687
и в командния интерпретатор, който ще се появи, изпълнете следните команди:
nmcli> rem ipv4.dns
nmcli> set ipv4.dns 127.0.0.1
nmcli> rem ipv6.dns
nmcli> set ipv6.dns ::1
nmcli> save
nmcli> activate
nmcli> quit
Ако командите бъдат изпълнени успешно, ще видите, че във файла /etc/resolv.conf ще се намират записи, които ще препращат DNS запитванията, които идват от приложенията локално, към локалния BIND (последният ще ги препраща към DNS сървъра, който обслужва HPC инфраструктурата):
nameserver 127.0.0.1
nameserver ::1
Убедете се, че там няма други записи от типа "nameserver", освен посочените по-горе. Ако има други, трябва да проверите защо се намират там и да ги премахнете.
-
ако НЕ използвате NetworkManager за управление на мрежовите интерфейси (ръчно управление):
В този случай, ще трябва да използвате скриптовете в /etc/sysconfig/network-scripts и съответните конфигурационни файлове на интерфейсите. Ако интерфейсът, през който ще преминава комуникацията към DNS сървъра, обслужващ HPC инфраструктурата, е с име ens3, трябва да редактирате файла /etc/sysconfig/network-scripts/ifcfg-ens3 така, че в него да има следните записи:
DNS1=127.0.0.1
DNS2=::1
След като запишете промените в този файл, трябва последователно да дезактивирате и активирате въпросния мрежови интерфейс (това може да е рискова операция, ако достъпвате сървъра през SSH):
# ifdown ens3
# ifup ens3
Ако процеса на активация протече успешно, ще видите, че във файла /etc/resolv.conf ще се появят записи, които ще препращат DNS запитванията, които идват от приложенията локално, към локалния BIND (последният ще ги препраща към DNS сървъра, който обслужва HPC инфраструктурата):
nameserver 127.0.0.1
nameserver ::1
Убедете се, че там няма други записи от типа "nameserver", освен посочените по-горе. Ако има други, трябва да проверите защо се намират там и да ги премахнете.
|
