• Категории
  • Подписка
  • Разместить статью
27/09/10 7 4112 Атаки на службу DNS
-

Перенос зоны c первичного на вторичный DNS-сервер

Одной из особенностей службы DNS является возможность использования нескольких компьютеров для обслуживания DNS-запросов. Это позволяет избежать зависимости от безот­казной работы единственной машины. Поэтому, наряду с единственным первичным DNS-сервером, для домена создают один или несколько вторичных DNS-серверов, каждый из кото­рых должен получать полную информацию о зоне и периодически обновлять ее при возникно­вении каких-либо изменений. Процесс передачи данных первичным сервером для обновления базы данных вторичного сервера называют переносом зоны.

Для создания на компьютере вторичного DNS-сервера в файл named.conf необходимо добавить такие строки:

zone   «example.com»   {
type slave;  file «slave/example.com»;
masters { 172.20.10.28;   172.20.228.19; };
};

Проблема заключается в том, что хакер тоже может осуществить перенос данных всей DNS-зоны (если не предпринять мер противодействия) даже без запуска BIND. Рассмотрим пример того, как с помощью команды host можно получить данные всех записей NS, А и PTR целого домена:

machine$ host -t ns  example.com
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):

options   {

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   [192.168.1.34].61655  for  «example.org»   (acl)
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.10 : allow
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.


7 комментариев на «“Перенос зоны c первичного на вторичный DNS-сервер”»

  1. Ника:

    спасибо за интересную статью

  2. Zuljin:

    Для меня это тёмный лес. К счастью, с такими трудностями не сталкивался.

  3. я бы сказал не интересно, а разумно

  4. Спасибо за статью, очень подробно написано) Сохраню на всякий случай)

  5. moisvetnet19:

    Непонял, почему именно
    >172.18.10.1-20 : allow, AXFR=”example.com/example.org”
    172.18.10. : allow, AXFR=”example. com” ?

  6. black0wolf:

    Спасибо!
    Zuljin, для меня тоже)

  7. Огромное спасибо!! Долбался часа три пока статью не нашел… спасибо!

Добавить комментарий

Яндекс.Метрика