Перенос зоны c первичного на вторичный DNS-сервер
Одной из особенностей службы DNS является возможность использования нескольких компьютеров для обслуживания DNS-запросов. Это позволяет избежать зависимости от безотказной работы единственной машины. Поэтому, наряду с единственным первичным DNS-сервером, для домена создают один или несколько вторичных DNS-серверов, каждый из которых должен получать полную информацию о зоне и периодически обновлять ее при возникновении каких-либо изменений. Процесс передачи данных первичным сервером для обновления базы данных вторичного сервера называют переносом зоны.
zone «example.com» {
type slave; file «slave/example.com»;
masters { 172.20.10.28; 172.20.228.19; };
};
Проблема заключается в том, что хакер тоже может осуществить перенос данных всей DNS-зоны (если не предпринять мер противодействия) даже без запуска BIND. Рассмотрим пример того, как с помощью команды host можно получить данные всех записей NS, А и PTR целого домена:
example.com name server ns1.example.com
example.com name server ns2.example.com
machine$ host -l example.сom ns1.example.com
example.com name server nsl.example.com
example.com name server ns2.example.com
www.example.com has address 172.26.105.20
mailhost.example.com has address 172.26.105.31
mailbackup.example.com has address 172.26.105.20
172-26-105-31.example.com domain name pointer mailhost.example.com
db.example.com has address 172.26.105.21
anonftp.example.com has address 172.26.105.22
Команда host при использовании опции -l позволяет выполнить полный перенос зоны, т.е. в любое время можно будет просмотреть дополнительную информацию, например, с помощью опции -t any. Применение опции -v позволяет получить информацию в формате конфигурационного файла первичного DNS-сервера точно так же, как если бы перенос зоны осуществлялся с помощью BIND.
Для вторичных DNS-серверов возможность переноса зоны является необходимой для выполнения обновлений их баз данных. Но для всех остальных компьютеров операция переноса зоны должна быть запрещена, так как это позволит хакеру без особого труда получить список всех компьютеров, зарегистрированных в базе данных DNS, т.е. всех машин, подключенных к Internet. Даже если была установлена защита от зондирования с помощью утилиты ping, то предоставление хакеру возможности переноса зоны сведет на нет все усилия по защите информации о работающих компьютерах.
Как противодействовать переносу зоны
Для противодействия несанкционированному переносу зоны необходима настройка сервера имен, которая позволит выполнять перенос зоны только вторичным DNS-cepверам.
BIND
Ограничение количества вторичных DNS-серверов, для которых перенос зоны будет разрешен, может быть осуществлено благодаря указанию их IP-адресов в записи options (где перечисляются опции, влияющие на работу всего сервера) или с помощью опции allow-transfer в записи zone (определяющей особенности конкретной зоны) конфигурационного файла (named.conf):
…
allow-transfer { 172.16.10.192; };
…
}
zone “example.com” {
type master;
file «master/example.com»;
allow-transfer { 192.168.14.20; 192.168.80.29; };
};
zone «example.org» {
file «master/example.com» };
zone «example.net» {
masters { 10.14.102.18; };
file «slave/example.net»;
allow-transfer { none; };
}
В приведенном выше листинге для домена example.org перенос зоны разрешен только хосту с IP-адресом 172.16.10.192 (благодаря указанию в глобальной записи options), перенос зоны для домена example.com разрешен компьютерам с IP-адресами 192.168.14.20 и 192.168.80.29, и полностью запрещен процесс переноса зоны в домене example.net.
Убедитесь, что перенос зоны ограничен как на первичном, так и на вторичных DNS-серверах! Хотя это и может показаться не совсем логичным, но при отсутствии соответствующих ограничений даже вторичный сервер может использоваться для переноса зоны.
Любые попытки несанкционированного переноса зоны регистрируются с помощью syslog. В системном журнале им соответствуют примерно следующие записи:
named[102]: unapproved AXFR from [10.182.18.23].62028 for «example.com» (acl)
named[102]: unapproved AXFR from [192.168.1.35].61659 for «example.net» (acl)
Нередко подобные записи в журнале просто напоминают о существовании вторичных DNS-серверов, которые были неверно настроены системным администратором (исправить ситуацию нужно как можно скорее, так как после потери возможности обновления баз данных эти вторичные DNS-серверы используют устаревшую информацию). Но чаще эти записи свидетельствуют о попытках хакеров получить список работающих компьютеров данного домена.
Простой запрет переноса DNS-зоны еще не означает, что хакеру не удастся определить имена узлов локальной сети. Например, если будет известно (хотя бы из заголовка почтового сообщения) о наличии хоста с именем larry, то хакер может попытаться найти хосты с именами katty и curly. Поскольку в мире компьютеров часто соблюдаются стойкие традиции назначения имен хостам одной сети, то присутствие определенного имени компьютера может означать наличие других имен. Более подробную информацию о правилах назначения имен хостов можно получить, обратившись к документам RFC 1778 и 2100.
DJBDNS
При использовании DJBDNS вместо BIND опасность несанкционированного переноса зон возникает только при установке программы axfrdns. Эта программа необходима только для осуществления переноса зоны по протоколу TCP, когда BIND-cepверы используются в качестве вторичных DNS-серверов. Когда системный администратор сам управляет всеми DNS-серверами, ему нужно просто использовать утилиту rsync или scp для автоматической синхронизации информации зоны DNS с помощью копирования файлов /etc/tinydns/root/data и /etc/tinydns/root/data.cbd на вторичные DNS-серверы.
Если использование axfrdns все же необходимо, то в файле конфигурации tcp в корневом каталоге axfrdns (как правило, это /etc/axfrdns/) нужно указать, какие компьютеры получат возможность осуществлять перенос зоны. Каждая строка этого файла начинается с IP-адреса, после которого следует двоеточие, а затем слово deny (запретить) или allow (разрешить). Все компьютеры, для IP-адресов которых указано слово allow, будут иметь доступ ко всем DNS-записям первичного сервера имен. Можно указывать диапазон IP-адресов. Важнее всего, что в конце строки можно добавлять список зон, которые будут доступны для компьютера с этим IP-адресом. Таким образом, файл /etc/axfrdns/tcp может содержать следующие строки:
172.18.10.5 : deny
172.18.10.1-20 : allow, AXFR=»example.com/example.org»
172.18.10. : allow, AXFR=»example. com»
В этом случае компьютер 172.18.10.10 обладает неограниченными правами на перенос любой зоны, компьютеру 172.18.10.5 перенос зон запрещен полностью, компьютерам диапазона адресов 172.18.10.1-20 разрешается перенос зон example.com и example.org, а всем остальным компьютерам сети 172.16.10 разрешен перенос одной зоны example.com.
Для файла /etc/axfrdns/tcp доступны и другие параметры, но они, как правило, бесполезны для утилиты axfrdns. Более подробную информацию можно получить на man-странице tcprules.
Твитнуть
спасибо за интересную статью
Для меня это тёмный лес. К счастью, с такими трудностями не сталкивался.
я бы сказал не интересно, а разумно
Спасибо за статью, очень подробно написано) Сохраню на всякий случай)
Непонял, почему именно
>172.18.10.1-20 : allow, AXFR=”example.com/example.org”
172.18.10. : allow, AXFR=”example. com” ?
Спасибо!
Zuljin, для меня тоже)
Огромное спасибо!! Долбался часа три пока статью не нашел… спасибо!