• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

    На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.

    Запись на курс до 25 апреля. Получить промодоступ ...

Статья Как настроить первичный DNS сервер на CentOS

Домены имеют как минимум два DNS сервера, один называется первичным сервером имён (ns1), а другой — вторичным сервером имён (ns2). Вторичные сервера обычно задействуются при проблемах с первичным сервером DNS: если один сервер недоступен, то второй становится активным. Возможны и более сложные схемы с использованием балансировки нагрузки, файерволов и кластеров.

Все DNS записи определённого домена добавляются в первичный сервер имён. Вторичный сервер просто синхронизирует всю информацию, получая её от первичного, на основании параметров, заданных на первичном сервере.

Эта инструкция опишет, как создать первичный DNS сервер, работающий на CentOS. Пожалуйста, обратите внимание, что DNS сервер, представленный в этой инструкции, будет публичным DNS, это означает, что сервер будет отвечать на запросы от любого IP адреса. Как ограничить доступ к серверу, описано в этой инструкции.

Перед тем, как мы начнём, хотелось бы упомянуть, что DNS может быть установлен с или без chroot jail окружением. Окружение chroot jail ограничивает DNS сервер определённой директорией в системе, в отличие от полного системного доступа на сервере. Таким образом, любая уязвимость DNS сервера не скомпромитирует всю систему. Ограничение DNS сервера в определённой директории (процесс называется chrooting) также полезно в тестовых условиях.

Цель
Мы настроим DNS сервер в тестовых условиях для домена example.tst, который является гипотетическим (не существующим) доменом. Таким образом, мы не вмешаемся случайным образом в работу каких-либо реальных доменов.

В этом домене есть три следующих сервера.
СерверIP адресХостящиеся службы
Сервер A172.16.1.1Mailmail.example.tst
Сервер B172.16.1.2Web, FTP
ftp.example.tst
Сервер C172.16.1.3Primary DNS serverns1.example.tst
Мы настроем первичный DNS сервер и добавим необходимый домен и DNS записи как показанов в таблице.

Настраиваем имена хостов
Все хосты должны быть корректно определены с точки зрения . Это может быть сделано с использованием следующего метода.

Те, кто любит графический интерфейс, могут воспользоваться инструментами NetworkManaget. Для этого наберите команду nmtui. Откроется такой псевдографический интерфейс:
1575228635657.png

Выбираете «Изменить имя узла» и вводите ns1.example.tst

Когда готово, нажимаете [Tab] и ОК.
1575228667113.png

Ещё один способ, всего в одну команду:
Bash:
hostnamectl set-hostname ns1.example.tst
После установки, имя хоста может быть проверено следующей командой.
Bash:
# hostname
ns1.example.tst
Или так
Bash:
hostnamectl status
1575228687315.png

Перед тем, как перейти к следующему шагу, убедитесь, что имя хоста для всех серверов задано должным образом.

Установка пакетов
Мы будем использовать bind для DNS, который с лёгкостью может быть установлен командой yum.

Установка DNS без chroot:
Bash:
# yum install bind


Установка DNS с chroot:
Bash:
# yum install bind bind-chroot


Подготовка конфигурационных файлов
Как было упомянуто ранее, bind может быть настроен с или без chroot. Пути немного различаются, в зависимости от того, был ли установлен chroot.

Путь до конфигурационного файлаПуть до файлов зоны
Без chroot/etc//var/named/
С chroot/var/named/chroot/etc//var/named/chroot/var/named/
Можно использовать конфигурационный файл named.conf, который поставляется по умолчанию. Тем не менее, мы будем использовать другой примерный конфигурационный файл для простоты использования.

Делаем резервную копию файла /etc/named.conf
Bash:
cp /etc/named.conf /etc/named.conf.bak


Без chroot:
Bash:
# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /etc/named.conf


С chroot:
Bash:
# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /var/named/chroot/etc/named.conf


Теперь, когда есть резервная копия конфигурационного файла, а сам оригинальнвй файл изменён, двигаемся дальше.

Без chroot:
Bash:
# vim /etc/named.conf


С chroot:
Bash:
# vim /var/named/chroot/etc/named.conf
Следующие строки были добавлены/изменены.
Код:
options {
## путь до файлов зон ##
directory "/var/named";

## пенераправляем запросы на публичный DNS сервер Google для нелокальных доменов ##
forwarders { 8.8.8.8; };
};

## объявление прямой зоны для example.tst ##
zone "example.tst" IN {
        type master;
        file "example-fz"; ## файл для прямой зоны размещён в /var/named ##
        allow-update { none; };
};

## объявление обратной зоны для сети 172.16.1.0 ##
zone "1.16.172.in-addr.arpa" IN {
        type master;
        file "rz-172-16-1"; ## файл для обратной зоны размещён в /var/named ##
        allow-update { none; };
};


Подготовка файлов зон
Дефолтные файлы зон автоматически созданы в /var/named или /var/named/chroot/var/named (для chroot).

Подразумевая, что дефолтные файлы зон не представлены, мы можем скопировать файлы образцов из /usr

Без chroot:
Bash:
# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/


С chroot:
Bash:
# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/chroot/var/named
Отлично. Теперь дефолтные файлы зоны готовы, мы создаём наши собственные файлы зоны для example.tst и сети 172.16.1.0. Пока мы создаём файлы зоны, нужно помнить следующее.
  • Символ ‘@’ означает NULL в файлах зоны.
  • Каждая запись полного доменного имени (FQDN) заканчивается точкой ‘.’ например. mail.example.tst. Без точки, будут проблемы.
1. Прямая зона
Прямая зона содержит карту преобразований из имён в IP адреса. Для публичных доменов, DNS доменов, размещённых на хостингах, содержаться в файле прямой зоны.

Без chroot:
Bash:
# vim /var/named/example-fz


С chroot:
Bash:
# vim /var/named/chroot/var/named/example-fz
$TTL 1D
@       IN SOA  ns1.example.tst. mial.example.tst. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
IN NS      ns1.example.tst.
IN A       172.16.1.3
mail        IN A        172.16.1.1
        IN MX 10    mail.example.tst.
www        IN A        172.16.1.2
ns1        IN A        172.16.1.3
ftp        IN CNAME    www.example.tst.
Объяснение: Внутри файла зоны, SOA означает начало авторизации. Это полное доменное имя авторитетного сервера имен. После полного доменного имени, идёт контактный email адрес. Поскольку мы не можем использовать ‘@’ в mial@example.tst, мы перезаписываем email адрес как mial.example.tst.
  • NS: Имя сервера
  • A: A запись или запись адреса — это IP адрес
  • MX: Mail Exchanger запись. Здесь мы используем только один MX с приоритетом 10. В случае множества MX, мы можем использовать различные цифровые приоритеты. Нижний номер выигрывает. Например, MX 0 лучше чем MX 1.
  • CNAME: имя в каноническом виде. Если на сервере размещено множество служб, весьма вероятно, что множество имён будут преобразовываться к одному серверу. CNAME сигнализирует, что другие имена сервер может иметь и отсылает к имени, которое содержится в A записи.
2. Обратная зона

Обратная зона содержит карту преобразований из IP адресов в имена. Здесь мы создаём обратную зону для сети 172.16.1.0. В реальном домене, DNS сервер владельца публичного IP блока содержится в файле обратной зоны.

Без chroot:
Bash:
# vim /var/named/rz-172-16-1


С chroot
Bash:
# vim /var/named/chroot/var/named/rz-172-16-1
$TTL 1D
@       IN SOA  ns1.example.tst. sarmed.example.tst. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
IN NS      ns1.example.tst.
1        IN PTR    mail.example.tst.
2        IN PTR    www.example.tst.
3        IN PTR    ns1.example.tst.
Объяснение: Большинство используемых параметров в обратной зоне идентичный прямой зоне, кроме одного.
  • PTR: PTR или запись указателя, она указывает на полное доменное имя
Завершение

Теперь, когда файлы зон готовы, мы настроем разрешение файлов зоны.

Без chroot:
Bash:
# chgrp named /var/named/*


С chroot:
Bash:
# chgrp named /var/named/chroot/var/named/*


Сейчас мы зададим IP адрес DNS сервера.
Bash:
# vim /etc/resolv.conf
nameserver 172.16.1.3


Наконец, мы можем запустить службу DNS и убедиться, что она добавлена в автозапуск.
Bash:
# service named restart
# chkconfig named on
Когда DNS заработает, рекомендуется поглядывать в файл журнала /var/log/messages, поскольку он содержит полезную информацию о том, что происходит «за сценой». Если там нет ошибок, мы можем начать тестировать DNS сервер.

Тестирование DNS
Мы можем использовать dig или nslookup для тестирования DNS. Вначале, мы установим необходимые пакеты.
Bash:
# yum install bind-utils


1. Тестирование прямой зоны с использованием dig
Когда вы используете для тестирования dig, вам всегда следует искать статус "NOERROR". Любое другое состояние означает, что что-то не так.
Код:
# dig example.tst
Код:
;; ->>HEADER<<- opcode: QUERY,  status: NOERROR, id: 31184

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            86400   IN      A       172.16.1.3

;; AUTHORITY SECTION:
example.com.            86400   IN      NS      ns1.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.        86400   IN      A       172.16.1.3


2. Проверка PTR с помощью dig
Когда вы используете для тестирования dig, вам всегда следует искать статус "NOERROR". Любое другое состояние означает, что что-то не так.
Код:
# dig -x 172.16.1.1
Код:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415

;; QUESTION SECTION:
;1.1.17.172.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
1.1.16.172.in-addr.arpa. 86400  IN      PTR     mail.example.tst.

;; AUTHORITY SECTION:
1.16.172.in-addr.arpa.  86400   IN      NS      ns1.example.tst.

;; ADDITIONAL SECTION:
ns1.example.tst.        86400   IN      A       172.16.1.3


3. Проверка MX с помощью dig
Код:
# dig example.tst mx
Код:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35405

;; QUESTION SECTION:
;example.tst.                        IN      MX

;; ANSWER SECTION:
example.tst.         14366   IN      MX     10    mail.example.tst.

Подсказки при решении проблем
  1. У меня отключён SELinux.
  2. Убедитесь, что ваш файервол не блокирует UDP порт 53
  3. /var/log/messages должен содержать полезную информацию в случае, если что-то не так
  4. Убедитесь, что владельцев файлов зон является пользователь ‘named’
  5. Убедитесь, что IP адрес DNS сервера стоит на первом месте в /etc/resolv.conf
  6. Если вы используете example.tst в лабораторных условиях, убедитесь, что отсоединили сервер от Интернета, поскольку example.tst — это несуществующий домен.
Подытожим, этот урок фокусируется на хостинге домена example.tst в лабораторных условиях для демонстрационных целей. Пожалуйста, помните, что это не инструкция по созданию публичного DNS сервера, например DNS сервера, который отвечает на запросы от любых IP адресов. Если вы настраиваете рабочий DNS сервер, убедитесь, что проверили, какие политика относятся к публичным DNS. Другой урок освещает создание вторичного DNS, ограничение доступа к DNS серверу, и реализацию DNSSEC.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!