で、比較的容易な対策ですけど、「各 PC は外部の DNS からは検索できない」ようにする」「内部のDNSは、NS/A/AAAA/PTR/CNAMEレコードのみ返し、TXTレコードは返さない」ようにすればいいでしょう。 元々、TXTレコード自体は実運用に不要なコメント的なものであり(だからこそ、どんな情報でも載せられるので、今回のような悪用ができるわけですが)、 今時だとTXTの主な用法はSPFでしょうけど、これはクライアント側で情報取得できなくても問題ないですから、TXTレコードが取得できなくなっても実害はないかと。
OP53Bクルー? (スコア:0)
Google Public DNS終了のお知らせ
Re:OP53Bクルー? (スコア:2)
> OP53Bクルー?
> Google Public DNS終了のお知らせ
勘違いしているでしょう。外部の DNS レコードを検索できる限り、DNS キャッシュサーバが組織内だろうが外だろうが関係なさそうです。
完全に阻止するためには、各 PC は外部の DNS は検索できないようにしておいて、外部 Web サイト閲覧は（例外的に外部 DNS を検索できる）プロキシサーバ経由とすれば OK という話かと。
Re:OP53Bクルー? (スコア:3, 興味深い)
「DNSプロトコルを悪用して」とか「不正なDNSパケット」という説明が誤解を招きやすいと思いますね。
単に「DNSサーバが不正な情報を提供している」だけで、
通信上はあくまで「正規のDNSプロトコル用法」であり、通信されるパケットも「正規のDNSパケット」。やってることは「WWWサーバ上にC&C指示をHTMLファイルとして設置」して「HTTPプロトコルで司令をダウンロードする」のと同レベルなんですが、HTTP通信は内容の検閲やフィルタリングが容易ですが、DNS通信はそういうことをあんまりやってない、という抜け穴。
で、比較的容易な対策ですけど、「各 PC は外部の DNS からは検索できない」ようにする」「内部のDNSは、NS/A/AAAA/PTR/CNAMEレコードのみ返し、TXTレコードは返さない」ようにすればいいでしょう。
元々、TXTレコード自体は実運用に不要なコメント的なものであり(だからこそ、どんな情報でも載せられるので、今回のような悪用ができるわけですが)、
今時だとTXTの主な用法はSPFでしょうけど、これはクライアント側で情報取得できなくても問題ないですから、TXTレコードが取得できなくなっても実害はないかと。
そう考えると「OP53B」というのもあながち間違った運用じゃないと思います。
Re:OP53Bクルー? (スコア:2)
TXT レコードをフィルタするのは ALG などのアプリケーション層で、OP53B の ポート番号 53（レイヤー4）とはレイヤーが違います。
# OP25B と迷惑メールフィルターぐらい違う？
Re:OP53Bクルー? (スコア:2)
すみません、今度は私が勘違いしていました。一般 PC は OP53B ということですね。商用 ISP では許されないでしょうが。
Re: (スコア:0)
TXT レコードをフィルタするのは ALG などのアプリケーション層で、OP53B の ポート番号 53（レイヤー4）とはレイヤーが違います。
「各 PC は外部の DNS からは検索できない」という部分に対してOP53Bが有効という意味ではないでしょうか？
TXTレコードのフィルタは親コメントの通り内部DNSで。何らかのフィルタリング装置・ゲートウェイ等でやったら大量のDNSの検査処理で通信が遅くなりそうだ
#意外といけるのかなぁ
SPFでTXTを使用 (スコア:0)
TXTレコード自体は実運用に不要なコメント的なもの
SPFでTXTを使用しているのを知らないんだなあ。
Re:SPFでTXTを使用 (スコア:1)
その後ろの
の一文も読んで欲しかった。
SPF用のTXTレコードは、メールを受信したメールサーバが読めればいいのであって、末端のクライアントPCが知る必要はありません。
Re: (スコア:0)
少なくとも、SPFが具体的にどうTXTレコードを使っているのか知らないね。
Re: (スコア:0)
野良 DNS サーバの場合は透過プロキシで TXT をフィルタリングしたり、OP53B で防げても、正規の DNS サーバなら PTR, CNAME そのものをデータとして使われると、もうどうにもならん。(16進テキスト表記のホスト名とか)
まあ、何かあった時に速攻で捕まるかも知れんが。
Re: (スコア:0)
TXTレコードがダメならCNAMEとかMXレコード使われるんじゃない？
情報量は減るが、問い合わせ回数でカバー出来ちゃうし。やろうと思えばAレコードでもやれるかも知れないし。
sore.zenbu.burokku.suruno. IN CNAME dekinai.desho.zenbu.burokku.suruno.
Re: (スコア:0)
C&Cとの通信がどの程度の帯域を必要とするのか分かってないのですが、
Aレコードの問い合わせに対する返信には32ビットの情報を載せられますよね。AAAAなら128ビット。
それを、TTLを極小に設定して何度も問い合わせるか、ランダムなホスト名を引く振りして何度も通信をするかして増やしてやれば…
という抜け道は、別途「すごく不審なDNSクエリ」として落とす、というような運用で防げるもんなんでしょうか?
Re: (スコア:0)
じゃあ「DNS通信の制限やプロクシサーバーの利用」がどう対応策になるの?
Re: (スコア:0)
最初から要らなかったけどね
Re: (スコア:0)
日本みたいに、プロバイダDNSでドメイン改竄を使ってネット検閲をしている国がある限りは、必要でしょ。
いずれ中国みたいにpublic dnsへの通信を遮断するだろうと思ってたけど、良い口実ができたね。
Re: (スコア:0)
OP25Bと同じ流れだとすると、先ずはDNSSECへの移行を促されるはずなんだけど……。
# いつになったら普及するねん。
Re:OP53Bクルー? (スコア:1)
いや、今回の問題は「C&C指示用に独自ドメインを取得」したうえで、そのドメインに対する「正規のNSレコードが指し示す先の、正規のドメイン所持者が提供するDNSサーバ」が「C&C指示情報をTXTレコードとして返す」という状況。「正規のDNS情報」として指示を送っているので、DNSSECは無力ですよ。
別コメントに書きましたが、「TXTレコードの取得を禁じる」という対応の一環として「OP53B」という対策はあり得るかと思います。
Re: (スコア:0)
サーバ側が重くなるからかね？
Re: (スコア:0)
リンク先の図を見ればわかると思うけど無関係