Предоставление перенаправления DNS на сервер honeypot для известных плохих доменов

В настоящее время работает BIND на RHEL 5.4 и ищет более эффективный способ перенаправления DNS на сервер honeypot для большого (более 30000) списка запрещенных доменов.

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

Проблема с этой конфигурацией заключается в большом количестве времени, необходимом для загрузки всех более 30000 доменов, а также на управление самим файлом конфигурации списка доменов... если в этот файл попадут какие-либо ошибки, сервер BIND не запустится, что приведет к Автоматизация процесса немного пугает. Поэтому я ищу что-то более эффективное и потенциально менее подверженное ошибкам.

Запись named.conf:

include "blackholes.conf";

Пример записи blackholes.conf:

zone "bad-domain.com" IN { type master; file "/var/named/blackhole.zone"; allow-query { any; }; notify no; };

Записи blackhole.zone:

$ INCLUDE std.soa

@ NS ns1.ourdomain.com.
@ NS ns2.ourdomain.com.
@ NS ns3.ourdomain.com.

В 192.168.0.99
* В 192.168.0.99

Источник

4 ответа

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

rndc reconfig

Полный перезапуск / перезагрузка сервера все равно приведет к невозможности запуска.

Источник

Рассматривали ли вы альтернативу BIND? Я еще не использовал, но есть MySQL-управляемые альтернативы с веб-интерфейсами, такие как PowerDNS с Poweradmin. Это может сделать обновления менее подверженными ошибкам и рискованным. PowerDNS даже имеет инструмент для преобразования файла зоны BIND в SQL для миграции.

Кроме того, я могу спросить, является ли этот список общедоступным? Я очень заинтересован в этом сам.

Источник

Теоретически вы можете избежать медленной загрузки, сделав свой список чёрных дыр частью корневого файла подсказок (например, с помощью $INCLUDE), а затем изменить этот файл из hint к master, Этот последний бит необходим для предотвращения загрузки вашим сервером настоящих корневых ссылок из Интернета.

например, в named.ca:

a.root-servers.net.  IN A ....
m.root-servers.net.  IN A ....
$INCLUDE blackhole.zone

а затем в blackhole.zone:

$ORIGIN example.com.
@ IN 192.168.0.99
* IN 192.168.0.99

$ORIGIN example.net.
@ IN 192.168.0.99
* IN 192.168.0.99

; ad-infinitum

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

Тогда просто следуйте предложению @syn о запуске named-checkzone перед каждой перезагрузкой и / или перезагрузкой.

NB: я не проверял это.

Источник

Изменить: Извините, я не очень хорошо прочитал ваш вопрос. Я предлагаю то же самое, что и вы. Может быть, вы можете включить файл, сгенерированный из базы данных?

У меня есть файл dropDomain с:

$TTL 3600       ; 1 hour
@               IN SOA  xxxxxxxx.fr. dnsmaster.xxxxxxxx.fr. (
                2009112001 ; serial 20yymmdd+nn
                                900        ; refresh (15 minutes)
                                600        ; retry (10 minutes)
                                86400      ; expire (1 day)
                                3600       ; minimum (1 hour)
                                )
                        NS      dns1.xxxxxxxx.fr.
                        NS      dns2.xxxxxxxx.fr.
                        MX      0       smtp.xxxxxxx.fr.

*                       A       127.0.0.1

; vim:filetype=bindzone

Затем я просто добавляю домены из моего списка в named.conf.local:

# Master pour les zones que l'on ne veut plus resoudre (pirates, virus, prise en main a distance...)
zone "zzzzzzz.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
zone "yyyyyyy.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
zone "ttttttt.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };

Мне не нужно определять его в файле зоны, он является общим.

Источник
Другие вопросы по тегам