Портал > Документация > Инсталиране и настройка на BIND-базиран DNS сървър, поддържащ TSIG, под CentOS 7 и Scientific Linux 7
Инсталиране и настройка на BIND-базиран DNS сървър, поддържащ TSIG, под CentOS 7 и Scientific Linux 7
Съдържание:
- Предварителна информация
- Инсталиране на BIND софтуера
- Конфигуриране на BIND
- Установяване на TSIG комуникация между BIND и DNS клиенти
- Проверка дали BIND обслужва заявки
- Прочит на журналните ("log") файлове на BIND
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.server
# wget https://unite.uni-sofia.bg/docs/logging.conf
# wget https://unite.uni-sofia.bg/docs/clients.conf
# mkdir pki/tsig-keys
# chown root:named pki/tsig-keys
# chmod 750 pki/tsig-keys
# mv named.conf.server 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 адресите, които са описани в следните два реда (това са адресите, на които "слуша" демона на BIND named):
listen-on port 53 { 127.0.0.1; 192.168.122.100; };
listen-on-v6 port 53 { ::1; fccc:67c:20d0:ffff::100; };
Заменете IP адресите 192.168.122.100 и fccc:67c:20d0:ffff::100 с актуалните за системата, ако се налага, но не изтривайте 127.0.0.1 и/или ::1. След редакцията, запазете промените във файла и го затворете.
След това, създайте ключ, с помощта на когото инструмента 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
Ако rndc комуникира успешно с 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 подписване, който да споделите с DNS клиент, работещ върху HPC изчислителен сървър, трябва да изпълните следния команден ред (не е нужно да сте super user, sudo):
$ rndc-confgen -a -b 512 -A hmac-sha256 -k "node001.unite.uni-sofia.bg" -u named -c node001.unite.uni-sofia.bg.key -r /dev/urandom
В този команден ред node001.unite.uni-sofia.bg е името на ключа, а node001.unite.uni-sofia.bg.key е името на файла, в който ключа ще бъде запазен. Изберете уникално име за всеки ключ (и уникално име на файл)!
Преди да изпратите ключа на администратора на сървъра от HPC инфраструктурата, в които ще се изпълнява процеса на DNS клиента, трябва да включите този ключ в списъка с ключове, които демона named може да чете и използва, и да разрешите обслужването на TSIG заявки, подписани с този ключ. За целта, копирайте файла с ключа в директория /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/clients.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/clients.conf трябва да добавите името на ключа в acl с име "recursive_clients":
acl recursive_clients {
key "node001.unite.uni-sofia.bg";
};
Ако този acl запис не съществува - създайте го. Ако съществува и трябва да добавите ново име на ключ в него, просто го добавете на нов ред между "{" и "}", например:
acl recursive_clients {
key "node001.unite.uni-sofia.bg";
key "node002.unite.uni-sofia.bg";
key "node003.unite.uni-sofia.bg";
};
Запазете промените във файла /var/named/chroot/etc/clients.conf и го затворете. След това проверете коректността на стартовата конфигурация на BIND, изпълнявайки:
# named-checkconf -t /var/named/chroot/
Ако при изпълнението не възникне съобщение за грешка, накарайте демона named да прочете променената конфигурация (в която е включен новия ключ):
# rndc reconfig
5. Проверка дали BIND обслужва заявки
Може да използвате инструмента dig (той е част от вече инсталирания пакет bind-utils) за да направите проверка дали демона named приема за обслужване заявки:
$ dig @::1 -t a www.uni-sofia.bg
Ако заявки се обслужват, ще получите отговор, в който ще има информацията, която сте заявили:
; <<>> 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 комуникацията между сървъра и DNS клиентите е успешна, може да проверите съдържанието на файла /var/named/chroot/var/log/named/queries.log. Записите там за успешно изпълнени заявки, ще изглеждат приблизително така:
04-Apr-2019 07:33:22.025 queries: client fccc:67c:20d0:ffff::101#41357/key node001.unite.uni-sofia.bg (www.uni-sofia.bg): query: www.uni-sofia.bg IN A +SE (fccc:67c:20d0:ffff::100)
04-Apr-2019 07:34:28.164 queries: client fccc:67c:20d0:ffff::101#51049/key node001.unite.uni-sofia.bg (www.uni-sofia.bg): query: www.uni-sofia.bg IN A +SE (fccc:67c:20d0:ffff::100)
04-Apr-2019 07:34:35.316 queries: client fccc:67c:20d0:ffff::101#38751/key node001.unite.uni-sofia.bg (www.uni-sofia.bg): query: www.uni-sofia.bg IN ANY +SE (fccc:67c:20d0:ffff::100)
Забележете, че тези записи включват не само IP адреса на DNS клиента, но и името на ключа, с който е извършен цифровия подпис върху TSIG заявките.
Ако има отхвърлени заявки, те ще бъдат описани във файла /var/named/chroot/var/log/named/security.log. Например:
04-Apr-2019 07:23:27.034 security: client fccc:67c:20d0:ffff::101#46402 (www.dir.bg): query (cache) 'www.dir.bg/A/IN' denied
04-Apr-2019 07:28:27.501 security: client fccc:67c:20d0:ffff::101#47873 (www.dir.bg): query (cache) 'www.dir.bg/A/IN' denied
04-Apr-2019 07:28:28.860 security: client fccc:67c:20d0:ffff::101#43072 (www.dir.bg): query (cache) 'www.dir.bg/A/IN' denied
показаните тук редове са индикация, че клиентът с IPv6 адрес fccc:67c:20d0:ffff::101 не може да запитва DNS сървъра и следователно не може да очаква отговор на заявките си (запитванията са забранени от конфигурацията на BIND).
|
