2016年2月1日にラックがDNSプロトコルを悪用した攻撃に関する注意喚起を行いました。本稿ではこれを受け、万一の事態に備えたDNSのクエリログの取得方法について解説します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
2016年2月1日〜3月18日は「サイバーセキュリティ月間」ということで、「コラムの1本でも」と思っていたのですが、何とか間に合わせることができました。もう終了してしまいましたが、2月から3月にかけて、「@IT セキュリティセミナー」が開催されました。筆者も、毎年恒例となっている辻伸弘氏、根岸征史氏とのトークセッションに登壇しました。読者の皆さんは、ご参加いただけたでしょうか? 参加できなかったという方はレポート記事を楽しみに待ちましょう。
さて、このセミナーでも取り上げた話題なのですが、2016年2月1日にラックが「遠隔操作ウイルスの制御にDNSプロトコルを使用する事案への注意喚起」を発信しました。既に1カ月以上も前のことなので、忘れてしまっている方もいるかもしれません。DNS通信を悪用するタイプのマルウェアがこれまで全くなかったわけではないのですが、「今、DNSが本格的に狙われており、見過ごすことはできない。危機感を喚起する必要がある」という判断から、今回の発信に至りました。
この問題を見過ごせないのは、非常に多くのシステムがDNSを経由してインターネットにつながっているからです。「このシステムはインターネットから隔離されている」「このシステムからWeb閲覧やメールの送受信はできない」とされているシステムであっても、“内部のDNSサーバを指定しているケース”はよくあるはずです。
筆者は、この内部のDNSサーバを経由して、攻撃者が管理するDNSサーバとの通信が可能になってしまっているシステムが多くあるのではないかと考えています。例えば、インターネットにつながっていないとされているシステムでも、このページのドメインである「www.atmarkit.co.jp」を名前解決して、IPアドレスを取得できてしまいませんか?
2015年の日本年金機構の情報漏えい事件やマイナンバー制度開始をきっかけに、重要情報が格納されているシステムを分離した組織も多いと思います。しかし、そのような分離されたシステムであっても、DNSだけは内部のDNSサーバを通じてインターネットと通じているケースが多くあります。その事実が認知されていないのではないかと筆者は危惧しています。
また、「DNSサーバの動作ログを記録していても、DNSのクエリログまで取得している組織はほとんどない」ということも懸念しています。これでは後からDNS通信を悪用するマルウェアに関する情報を入手できたとしても、自組織で被害が発生していたかを確認することができません。今すぐシステムの構成を変更することが難しい組織は多いとは思いますので、DNS通信を悪用する攻撃が増える前に、せめてDNSクエリログの取得を検討してもらいたいと思います。以下で、「BIND」と「Windows Server」における具体的な設定方法を紹介します。
DNSサーバとして「BIND」を使用している場合は、BINDの設定ファイル(「/etc/named.conf」など)に、以下のように設定を行います。
logging { channel "queries_log" { file "/var/log/queries.log" versions 10 size 100M; severity info; print-time yes; }; category queries { "queries_log"; }; };
これは「/var/log/queries.log」というファイルにクエリログを記録する設定です。ログファイルのサイズは1つ当たり100MBで、10個のログファイルをローテーションで使用するように指定しています。あとは、ログファイルにBINDが書き込みを行えるようにオーナやパーミッションを設定し、BINDの再起動をします。これでクエリログが以下のように書き込まれるようになります。
10-Feb-2016 01:05:35.940 client 192.168.1.1#38846: query: www.kawa.local IN A + (xxx.xxx.xxx.162) 10-Feb-2016 01:05:56.580 client 192.168.1.1#38846: query: in.kawa.local IN A + (xxx.xxx.xxx.162)
Copyright © ITmedia, Inc. All Rights Reserved.