Допустим Fail2Ban уже установлен, если нет, то смотрите мою статью — Установка и настройка Fail2ban.
По умолчанию Bind9 не пишет логи, поэтому откроем его файл конфигурации в любом текстовом редакторе:
sudo nano /etc/bind/named.conf
И добавим:
logging {
channel security_file {
file "/var/log/named/security.log" versions 3 size 30m;
severity dynamic;
print-time yes;
};
category security {
security_file;
};
};
Настроить обратную DNS запись (PTR) для Hetzner сервера можно в панели управления Robot
Нажав слева «Servers» — выбрав сервер, и кликнув по IP адресу севера появится поле ввода «Reverse DNS», где её и нужно указать.
После настройки, на моей практике изменения вступали в силу в течении суток.
Смотрите также:
Настройка PTR записи на DNS сервере
На примере опишу вариант мониторинга DNS сервера Bind9 в Zabbix.
Для начала включим статистику Bind9, откроем файл конфигурации в текстовом редакторе, например nano (Ctrl+X для выхода, y/n для сохранения или отмены изменений):
sudo nano /etc/bind/named.conf
И добавим следующие строки (где первый IP и порт — интерфейс на котором будет видна статистика, а следующие — с которых разрешен к ней доступ):
statistics-channels {
inet 192.168.10.1 port 8053 allow { 127.0.0.1; 192.168.10.1; 192.168.10.15;};
};
И перезапустим Bind чтобы применить изменения:
sudo /etc/init.d/bind9 restart
После этого в браузере набрав http://192.168.10.1:8053/ можно увидеть статистику Bind9.
Установим необходимые компоненты необходимые для получения статистики из терминала:
sudo apt-get install xml2 curl
Проверим отображается ли статистика:
curl http://192.168.10.1:8053/ 2>/dev/null | xml2 | grep -A1 queries
Теперь допишем к конфигурацию Zabbix агента /etc/zabbix/zabbix_agentd.conf параметры которые будем мониторить:
# Количество udp соединений к DNS: UserParameter=bind.net.udp,netstat -nua | grep :53 | wc -l # Количество tcp соединений к DNS: UserParameter=bind.net.tcp,netstat -nta | grep :53 | wc -l # Количество входящих и исходящих запросов: UserParameter=bind.queries.in[*],curl http://192.168.10.1:8053/ 2>/dev/null | xml2 | grep -A1 "/isc/bind/statistics/server/queries-in/rdtype/name=$1$" | tail -1 | cut -d= -f2 UserParameter=bind.queries.out[*],curl http://192.168.10.1:8053/ 2>/dev/null | xml2 | grep -A1 "/isc/bind/statistics/views/view/rdtype/name=$1$" | tail -1 | cut -d= -f2
И перезапустим Zabbix агент чтобы применить изменения:
sudo /etc/init.d/zabbix-agent restart
Добавим элементы данных и графики нужному узлу сети или шаблону в Zabbix сервере (тип — Zabbix агент, примеры ключей ниже):
bind.queries.in[A] bind.queries.out[A] bind.queries.in[AAAA] bind.queries.out[AAAA] bind.queries.in[NS] bind.queries.out[NS] bind.queries.in[MX] bind.queries.out[MX] bind.queries.in[PTR] bind.queries.out[PTR] bind.queries.in[SOA] bind.queries.out[SOA] bind.queries.in[TXT] bind.queries.out[TXT] bind.queries.in[ANY] bind.queries.out[ANY] и т.д.
Понадобилось как-то настроить обратную DNS зону (Reverse DNS) для почтового сервера, так как некоторые сервера не хотели принимать от него почту.
Допустим наш домен mail.example.com находящийся на IP адресе 192.168.1.100, а 192.168.1.1 — сервер интернет провайдера.
Проверить из Windows можно командами (где 192.168.1.100 например адрес нашего почтового сервера, а 192.168.1.1 DNS на который шлем запрос):
nslookup mail.example.com nslookup 192.168.1.100 nslookup 192.168.1.100 192.168.1.1
В ответ первой команды будет 192.168.1.100, а в ответ второй ничего (должно mail.example.com), так как в DNS не настроена PTR запись.
Из Linux проверять можно так:
dig -x 192.168.1.100
У регистратора доменных имен в DNS добавим дочерний NS-сервер интернет провайдера ns1.example.com 192.168.1.1.
На сервере провайдера (на тесте использую Bind9 на Ubuntu Server) откроем конфигурационный файл DNS сервера например в редакторе nano (CTRL+X для выхода, y/x и Enter для сохранения или отмены изменений):
sudo nano /etc/bind/named.conf
И добавим следующие строки:
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/1.168.192.in-addr.arpa";
};
Первая строка указывает какой зоной будем управлять, вторая тип — главный (этот DNS и будет ею управлять), третья — в каком файле будет прописана конфигурация для этой зоны.
Откроем новый файл для настроек зоны:
sudo nano /etc/bind/1.168.192.in-addr.arpa
И добавим в него:
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2016112301 ; Serial
21600 ; refresh
3600 ; retry
3600000 ; expire
86400 ) ; minimum
IN NS ns1.hosting.com.
IN NS ns2.hosting.com.
$ORIGIN 1.168.192.in-addr.arpa.
100 IN PTR mail.example.com.
admin.example.com — контактный адрес человека отвечающего за зону, символ @ не указывается.
Serial это серийный номер версии файла зоны, должен изменяться в большую сторону при каждом изменении, обычно пишется в виде год месяц число номер изменения, по нему другие DNS определяют что нужно обновить у себя информацию.
Refresh — интервал времени в секундах, через который вторичный сервер будет проверять необходимость обновления информации.
Retry — интервал времени в секундах, через который вторичный сервер будет повторять обращения при неудаче.
Expire — интервал времени в секундах, через который вторичный сервер будет считать имеющуюся у него информацию устаревшей.
Minimum — интервал времени жизни информации на кэширующих серверах.
ns1.hosting.com и ns2.hosting.com это DNS домена.
Цифра 100 в последней строке означает окончание IP адреса 192.168.1, аналогично можно указывать записи для других доменов, например 101 IN PTR … для 192.168.1.101 и т.д.
Перезапустим DNS сервер чтобы применить изменения.
Bind9 можно командой:
sudo /etc/init.d/bind9 restart
Смотрите также:
Настройка Reverse DNS (PTR) в Hetzner
По умолчанию логи Bind9 записываются в системный журнал /var/log/syslog и чтобы отделить их, выполним действия которые я укажу ниже.
На тесте буду настраивать Bind9 в Ubuntu Server 16.04.
Откроем основной файл конфигурации Bind9 например в редакторе nano (Ctrl+X для выхода, y/x для сохранения или отмены изменений):
sudo nano /etc/bind/named.conf
Добавим в его конец:
logging {
channel bind.log {
file "/var/lib/bind/bind.log" versions 10 size 20m;
severity notice;
print-category yes;
print-severity yes;
print-time yes;
};
category queries { bind.log; };
category default { bind.log; };
category config { bind.log; };
};
Второй пример, либо можно настроить сохранение логов в разные файлы:
logging {
channel "misc" {
file "/var/log/named/misc.log" versions 4 size 4m;
print-time YES;
print-severity YES;
print-category YES;
};
channel "query" {
file "/var/log/named/query.log" versions 4 size 4m;
print-time YES;
print-severity NO;
print-category NO;
};
category default {
"misc";
};
category queries {
"query";
};
};
severity указывает уровень логирования, он может быть: critical, error, warning, notice, info, debug, dynamic.
Перезапустим Bind9 чтобы применить изменения:
sudo /etc/init.d/bind9 restart
Можно сделать ссылку в /var/log/, чтобы другим было легче их найти:
sudo ln -s /var/lib/bind/ /var/log/
Смотреть логи в реальном времени можно командой (Ctrl+C остановка просмотра):
sudo tail -f /var/lib/bind/bind.log
Если запись логов ведется в нестандартную директорию, то нужно разрешить это в apparmor:
sudo nano /etc/apparmor.d/usr.sbin.named
Смотрите также:
Установка и настройка DNS-сервера BIND9
Для мониторинга самой службы DNS на порту можно использовать следующий ключ в элементах данных (где СЕРВЕР, это IP-адрес или домен DNS сервера):
net.tcp.dns[СЕРВЕР]
Чтобы не создавать с нуля шаблон, можно клонировать например стандартный «Template App SSH Service» изменив в нём название и указав новый ключ, триггер изменится автоматически. А также в «Тип» выберем «Zabbix агент» вместо простой проверки.
Следующей командой можно выполнить проверку из командной строки Linux:
zabbix_get -s127.0.0.1 -k'net.tcp.dns[СЕРВЕР]'
Естественно если ответом будет 1, то служба DNS запущена, 0 — нет.
SPF (инфраструктура политики отправителей) позволяет указать в TXT записи DNS параметров домена адреса с которых возможна отправка почты чтобы предотвратить e-mail spoofing.
Приведу пример добавления SPF записей:
v=spf1 +a +mx -all v=spf1 ip4:192.168.1.5 ip4:192.168.7.111 +a +mx -all
Где, v=spf1 — версия SPF,
ip4:АДРЕС IP-адрес с которого разрешена отправка почты,
+a разрешает прием почты от адресов которые указаны в A-записях домена,
+mx разрешает прием почты если адрес указан MX-записи домена,
-all отвергать все остальные сообщения, не прошедшие проверку.
В Linux преобразовать список IP-адресов в DNS-имена можно например простеньким скриптом.
Для этого создадим пустой файл с расширением .sh, сделаем его исполняемым и добавим в него содержимое:
#!/bin/sh
while read ip traf ; do
name=`host $ip|awk '{print $NF}'`
echo -e "$name\t$ip\t$traf"
done >name_ip_traf.lst <ip_traf.lst
Где ip_traf.lst — файл со списком IP-адресов которые необходимо преобразовать в DNS-имена.
Исполняемым его можно сделать командой:
chmod +rwx скрипт.sh
Запускать скрипт необходимо находясь в директории где он находится командой:
./скрипт.sh
После запуска необходимо подождать некоторое время либо оборвать выполнение комбинацией клавиш CTRL+C.
Устанавливается утилита в Ubuntu/Debian командой:
sudo apt-get install dnstop
Пример запуска:
dnstop -n vk.com em1
Опишу список возможных ключей запуска:
-4 (количество IPv4 пакетов)
-6 (количество IPv6 пакетов)
-Q (количество запросов)
-R (количество ответов)
-a (анонимные IP-адреса)
-i адрес (игнорирование указанного IP-адреса)
-n имя (количество запросов только для указанного адреса)
-l число (мониторинг до указанного числа запросов)
-f (имя фильтра)
Начиная от версии RouterOS v6.14 добавлена функция Cloud, которая позволяет использовать Dynamic DNS имя для устройства, которое автоматически назначается и по нему можно получить доступ даже если IP адрес будет изменятся.
Пример включения через консоль:
ip cloud set enabled=yes
Пример просмотра параметров:
ip cloud print
Включение обновления времени устройства с временем DDNS сервера (если не настроен SNTP или NTP сервис):
ip cloud update-time yes/no
Немедленное обновление DDNS:
ip cloud force-update
Просмотр DDNS имени:
ip cloud dns-name
Просмотр публичного IP адреса на который привязан DDNS:
ip cloud public-address
Привязка DDNS к локальному IP-адресу вместо публичного, например к 192.168.1.101 и т.д.)
ip cloud advanced use-local-address yes/no
Просмотр текущего статуса Cloud (обновляется, обновлен, ошибка и т.д.):
ip cloud status
Через графический интерфейс настройки Cloud можно найти в меню «IP» — «Cloud».