web-dev-qa-db-ja.com

既知の不良ドメインのハニーポットサーバーへのDNSリダイレクトの提供

現在RHEL5.4でBINDを実行しており、禁止ドメインの大規模な(30,000以上)リストに対してハニーポットサーバーにDNSリダイレクトを提供するより効率的な方法を探しています。

この要件に対する現在の解決策は、named.confにブロックされたドメインごとのゾーンマスター宣言を含むファイルを含めることです。その後、これらの各ゾーン宣言は同じゾーンファイルを指し、そのドメイン内のすべてのホストをハニーポットサーバーに解決します。 ...基本的に、これにより、内部システムに侵入する可能性のあるマルウェアによる「電話ホーム」の試みをキャプチャできます。

この構成の問題は、30,000以上のドメインすべてのロードに時間がかかることと、ドメインリスト構成ファイル自体の管理です...このファイルにエラーが発生すると、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。

IN A 192.168.0.99
* IN A 192.168.0.99

3
syn-

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:私はこれをテストしていません。

1
Alnitak

各ドメインを独自のゾーンにロードする必要をなくす良い方法は見つかりませんでしたが、次のrndcコマンドを使用すると、エントリの形式が正しくない場合にサーバーが失敗する心配がなくなります。

rndc reconfig

サーバーの再起動/再読み込みがいっぱいになると、起動に失敗します。

0
syn-

編集:申し訳ありませんが、あなたの質問をよく読みません。私はあなたと同じことを提案します。多分あなたはデータベースから生成されたファイルを含めることができますか?

私は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; }; };

ゾーンファイルで定義する必要はありません。一般的なものです。

0
Dom

BINDの代替案を検討しましたか?私はまだ使用していませんが、Poweradminを備えたPowerDNSなど、Webフロントエンドを備えたMySQL主導の代替手段があります。これにより、更新のエラーが発生しにくくなり、リスクが低くなる可能性があります。 PowerDNSには、移行のためにBINDゾーンファイルをSQLに変換するツールもあります。

また、そのリストが公開されているかどうかを尋ねることはできますか?私自身、これにとても興味があります。

0
Aaron Copley