(1/2)2016年2月1日にラックがDNSプロトコルを悪用した攻撃に関する注意喚起を行いました。本稿ではこれを受け、万一の事態に備えたDNSのクエリログの取得方法について解説します。});この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。連載目次DNS通信を悪用したマルウェアの存在2016年2月1日〜3月18日は「サイバーセキュリティ月間」ということで、「コラムの1本でも」と思っていたのですが、何とか間に合わせることができました。セキュリティセミナー」が開催されました。トークセッションに登壇しました。参加できなかったという方はレポート記事を楽しみに待ちましょう。このセミナーでも取り上げた話題なのですが、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クエリログの取得を検討してもらいたいと思います。Server」における具体的な設定方法を紹介します。DNS通信の記録——「BIND」の場合DNSサーバとして「BIND」を使用している場合は、BINDの設定ファイル(「/etc/named.conf」など)に、以下のように設定を行います。};};これは「/var/log/queries.log」というファイルにクエリログを記録する設定です。ログファイルのサイズは1つ当たり100MBで、10個のログファイルをローテーションで使用するように指定しています。あとは、ログファイルにBINDが書き込みを行えるようにオーナやパーミッションを設定し、BINDの再起動をします。これでクエリログが以下のように書き込まれるようになります。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。