パスワードを忘れた? アカウント作成
12675965 story
セキュリティ

DNSプロトコルを悪用して指令を受ける遠隔操作ウイルスが確認される 23

ストーリー by hylom
そこを使うか 部門より

DNSプロトコルを使って攻撃者と通信を行うマルウェアが確認されたそうだ(INTERNET Watchラックのプレスリリース)。

攻撃者はDNSサーバーに模した指令サーバーを使用し、一般的なDNSリクエストと同じパケットを使ってマルウェアとの通信を行っていたという。実際に確認された不正なDNSパケットでは、短時間内に不規則なサブドメイン名が付けられたドメイン名についてのリクエストが大量に送出されていたそうだ。このサブドメイン名を使って何らかの情報を送信していると見られる。

DNSは多くの環境で監視やブロックの対象外となっており、また指令サーバーの稼働時間が短いという特徴もあるため、検知は非常に難しいという。

対応策としてはDNS通信の制限やプロクシサーバーの利用などが挙げられている(遠隔操作ウイルスの制御にDNSプロトコルを使用する事案への注意喚起)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • VPN製品でDNSを使ってファイヤウォールを抜けるやつがあるけど、そういうたぐいの手法?

    • by Anonymous Coward

      便利だよね。target.evil.example.comを引くと、
      「DDoSアタックを仕掛けるべきターゲットのIPアドレス」という形で指令が帰って来るようにするとか、実装がすごく楽そう。

      自分に自分で一人DDoS攻撃を仕掛けても、目に見えるほどの影響は出ないだろうから、
      特に攻撃を仕掛ける対象がないときは127.0.0.1を返しておくという運用で、
      例外処理すらしないというずぼらな実装でも一般的なユーザには気付かれなさそう。

      • by Anonymous Coward

        年末の仕事納めの日
        空いているHUBのポートにLANケーブル両端繋がれて
        目に見えるほどの影響でたなぁ

        # 物理アタックなら無知な素人も即戦力

        • by Anonymous Coward

          つ スパニングツリー対応HUB

          # 根元に1個置いておくだけでもだいぶ違うよ

  • by Anonymous Coward on 2016年02月03日 7時23分 (#2958695)

    Google Public DNS終了のお知らせ

    • by ogino (1668) on 2016年02月03日 9時25分 (#2958766) 日記

      > OP53Bクルー?

      > Google Public DNS終了のお知らせ

      勘違いしているでしょう。外部の DNS レコードを検索できる限り、DNS キャッシュサーバが組織内だろうが外だろうが関係なさそうです。

      完全に阻止するためには、各 PC は外部の DNS は検索できないようにしておいて、外部 Web サイト閲覧は(例外的に外部 DNS を検索できる)プロキシサーバ経由とすれば OK という話かと。

      親コメント
      • by taka2 (14791) on 2016年02月03日 10時09分 (#2958810) ホームページ 日記

        「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」というのもあながち間違った運用じゃないと思います。

        親コメント
        • by ogino (1668) on 2016年02月03日 10時30分 (#2958827) 日記

          TXT レコードをフィルタするのは ALG などのアプリケーション層で、OP53B の ポート番号 53(レイヤー4)とはレイヤーが違います。

          # OP25B と迷惑メールフィルターぐらい違う?

          親コメント
          • by ogino (1668) on 2016年02月03日 10時43分 (#2958834) 日記

            すみません、今度は私が勘違いしていました。一般 PC は OP53B ということですね。商用 ISP では許されないでしょうが。

            親コメント
          • by Anonymous Coward

            TXT レコードをフィルタするのは ALG などのアプリケーション層で、OP53B の ポート番号 53(レイヤー4)とはレイヤーが違います。

            「各 PC は外部の DNS からは検索できない」という部分に対してOP53Bが有効という意味ではないでしょうか?
            TXTレコードのフィルタは親コメントの通り内部DNSで。何らかのフィルタリング装置・ゲートウェイ等でやったら大量のDNSの検査処理で通信が遅くなりそうだ

            #意外といけるのかなぁ

        • by Anonymous Coward

          TXTレコード自体は実運用に不要なコメント的なもの

          SPFでTXTを使用しているのを知らないんだなあ。

          • その後ろの

            今時だとTXTの主な用法はSPFでしょうけど、これはクライアント側で情報取得できなくても問題ない

            の一文も読んで欲しかった。

            SPF用のTXTレコードは、メールを受信したメールサーバが読めればいいのであって、末端のクライアントPCが知る必要はありません。

            親コメント
          • by Anonymous Coward

            少なくとも、SPFが具体的にどうTXTレコードを使っているのか知らないね。

        • by Anonymous Coward

          野良 DNS サーバの場合は透過プロキシで TXT をフィルタリングしたり、OP53B で防げても、正規の DNS サーバなら PTR, CNAME そのものをデータとして使われると、もうどうにもならん。(16進テキスト表記のホスト名とか)

          まあ、何かあった時に速攻で捕まるかも知れんが。

        • by Anonymous Coward

          TXTレコードがダメならCNAMEとかMXレコード使われるんじゃない?
          情報量は減るが、問い合わせ回数でカバー出来ちゃうし。やろうと思えばAレコードでもやれるかも知れないし。

          sore.zenbu.burokku.suruno. IN CNAME dekinai.desho.zenbu.burokku.suruno.

        • by Anonymous Coward

          C&Cとの通信がどの程度の帯域を必要とするのか分かってないのですが、
          Aレコードの問い合わせに対する返信には32ビットの情報を載せられますよね。AAAAなら128ビット。
          それを、TTLを極小に設定して何度も問い合わせるか、ランダムなホスト名を引く振りして何度も通信をするかして増やしてやれば…

          という抜け道は、別途「すごく不審なDNSクエリ」として落とす、というような運用で防げるもんなんでしょうか?

      • by Anonymous Coward

        じゃあ「DNS通信の制限やプロクシサーバーの利用」がどう対応策になるの?

    • by Anonymous Coward

      最初から要らなかったけどね

      • by Anonymous Coward

        日本みたいに、プロバイダDNSでドメイン改竄を使ってネット検閲をしている国がある限りは、必要でしょ。
        いずれ中国みたいにpublic dnsへの通信を遮断するだろうと思ってたけど、良い口実ができたね。

    • by Anonymous Coward

      OP25Bと同じ流れだとすると、先ずはDNSSECへの移行を促されるはずなんだけど……。

      # いつになったら普及するねん。

      • いや、今回の問題は「C&C指示用に独自ドメインを取得」したうえで、そのドメインに対する「正規のNSレコードが指し示す先の、正規のドメイン所持者が提供するDNSサーバ」が「C&C指示情報をTXTレコードとして返す」という状況。「正規のDNS情報」として指示を送っているので、DNSSECは無力ですよ。

        別コメントに書きましたが、「TXTレコードの取得を禁じる」という対応の一環として「OP53B」という対策はあり得るかと思います。

        親コメント
      • by Anonymous Coward

        サーバ側が重くなるからかね?

    • by Anonymous Coward

      リンク先の図を見ればわかると思うけど無関係

typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...