現在RHEL5.4でBINDを実行しており、禁止ドメインの大規模な(30,000以上)リストに対してハニーポットサーバーにDNSリダイレクトを提供するより効率的な方法を探しています。
この要件に対する現在の解決策は、named.confにブロックされたドメインごとのゾーンマスター宣言を含むファイルを含めることです。その後、これらの各ゾーン宣言は同じゾーンファイルを指し、そのドメイン内のすべてのホストをハニーポットサーバーに解決します。 ...基本的に、これにより、内部システムに侵入する可能性のあるマルウェアによる「電話ホーム」の試みをキャプチャできます。
この構成の問題は、30,000以上のドメインすべてのロードに時間がかかることと、ドメインリスト構成ファイル自体の管理です...このファイルにエラーが発生すると、BINDサーバーの起動に失敗し、プロセスの自動化は少し恐ろしいです。そのため、より効率的でエラーが発生しにくいものを探しています。
include "blackholes.conf";
zone "bad-domain.com" IN { type master; file "/var/named/blackhole.zone"; allow-query { any; }; notify no; };
$ INCLUDE std.soa
@ NS ns1.ourdomain.com。
@ NS ns2.ourdomain.com。
@ NS ns3.ourdomain.com。IN A 192.168.0.99
* IN A 192.168.0.99
theoryでは、ブラックホールリストをルートヒントファイルの一部にして(たとえば、$INCLUDE
経由)、変更することで、読み込みに時間がかかるのを防ぐことができます。そのファイルはhint
からmaster
になります。この最後のビットは、サーバーがインターネットからrealルートヒントをダウンロードしないようにするために必要です。
例えば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
ステートメントは必要ありません。ルートゾーンのローカルコピーに偽の信頼できるデータを効果的に挿入しています。あなたは時々本当のルートゾーンをダウンロードします!
次に、各リロードや再起動の前にnamed-checkzone
を実行するという@synの提案に従ってください。
NB:私はこれをテストしていません。
各ドメインを独自のゾーンにロードする必要をなくす良い方法は見つかりませんでしたが、次のrndcコマンドを使用すると、エントリの形式が正しくない場合にサーバーが失敗する心配がなくなります。
rndc reconfig
サーバーの再起動/再読み込みがいっぱいになると、起動に失敗します。
編集:申し訳ありませんが、あなたの質問をよく読みません。私はあなたと同じことを提案します。多分あなたはデータベースから生成されたファイルを含めることができますか?
私は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; }; };
ゾーンファイルで定義する必要はありません。一般的なものです。
BINDの代替案を検討しましたか?私はまだ使用していませんが、Poweradminを備えたPowerDNSなど、Webフロントエンドを備えたMySQL主導の代替手段があります。これにより、更新のエラーが発生しにくくなり、リスクが低くなる可能性があります。 PowerDNSには、移行のためにBINDゾーンファイルをSQLに変換するツールもあります。
また、そのリストが公開されているかどうかを尋ねることはできますか?私自身、これにとても興味があります。