DNSプロトコルを悪用して指令を受ける遠隔操作ウイルスが確認される 23
ストーリー by hylom
そこを使うか 部門より
そこを使うか 部門より
DNSプロトコルを使って攻撃者と通信を行うマルウェアが確認されたそうだ(INTERNET Watch、ラックのプレスリリース)。
攻撃者はDNSサーバーに模した指令サーバーを使用し、一般的なDNSリクエストと同じパケットを使ってマルウェアとの通信を行っていたという。実際に確認された不正なDNSパケットでは、短時間内に不規則なサブドメイン名が付けられたドメイン名についてのリクエストが大量に送出されていたそうだ。このサブドメイン名を使って何らかの情報を送信していると見られる。
DNSは多くの環境で監視やブロックの対象外となっており、また指令サーバーの稼働時間が短いという特徴もあるため、検知は非常に難しいという。
対応策としてはDNS通信の制限やプロクシサーバーの利用などが挙げられている(遠隔操作ウイルスの制御にDNSプロトコルを使用する事案への注意喚起)。
VPN over DNSみたいなもの? (スコア:2)
VPN製品でDNSを使ってファイヤウォールを抜けるやつがあるけど、そういうたぐいの手法?
Re: (スコア:0)
便利だよね。target.evil.example.comを引くと、
「DDoSアタックを仕掛けるべきターゲットのIPアドレス」という形で指令が帰って来るようにするとか、実装がすごく楽そう。
自分に自分で一人DDoS攻撃を仕掛けても、目に見えるほどの影響は出ないだろうから、
特に攻撃を仕掛ける対象がないときは127.0.0.1を返しておくという運用で、
例外処理すらしないというずぼらな実装でも一般的なユーザには気付かれなさそう。
Re: (スコア:0)
年末の仕事納めの日
空いているHUBのポートにLANケーブル両端繋がれて
目に見えるほどの影響でたなぁ
# 物理アタックなら無知な素人も即戦力
Re: (スコア:0)
つ スパニングツリー対応HUB
# 根元に1個置いておくだけでもだいぶ違うよ
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)
リンク先の図を見ればわかると思うけど無関係