ITの窓辺から

三流IT技術者の日常

Splunk Universal Forwarderの設定 (1)

今日もSplunkです。バージョン7.1.1です。Splunkではないマシンのログを取り組むための手段の一つにSplunkが提供しているエージェントソフトウェアを使うというものがあります。これの設定がマニュアルを見ているだけだとなかなか分かりづらく、今回の記事はその試行錯誤の一部を書いてみたものになります。

 ユニバーサルフォワーダによるログの送信

ユニバーサルフォワーダはSplunkが提供しているログ送信用エージェントソフトウェアです。ユニバーサルフォワーダを使うとSyslog等に頼らずSplunkにリモートマシンからログを送信することができます。マニュアルによると色々な分散構成やプロキシ的な中継構成が取れるようですが、今回はシンプルに1台のインデクサ(これまでSplunkとして使ってきたマシン)に送信する構成にします。

インストールと設定

ユニバーサルフォワーダ(以下フォワーダ)はSplunkのサイトからダウンロードできます。アカウント登録が必要ですが、Splunk本体のダウンロードにもアカウントは必要なので特に問題にはならないでしょう。WindowsMacOSLinuxUnix等多くのOSにインストール可能です

まずはWindows Server2012R2にインストールしてみます。MSI形式で配布されているので素直にダブルクリックするだけでOKです。色々と入力項目が出てきますが後で変更できるので、適当に入力すれば大丈夫でしょう。インストール後に正常にサービスが起動しることを確認します。

f:id:ReaLiZeZNSG:20180715182935p:plain

Splunkのインデクサ側でフォワーダからの通信を受け入れる設定をします。

f:id:ReaLiZeZNSG:20180715182637p:plain

転送と受信、データの受信とたどり待受ポートを設定します。デフォルトでは宛先ポートTCP9997で通信するようなので素直に従います。

インストール時に正しくインデクサを指定しており、Windowsのイベントログを送信する設定にしていれば、もうログが飛んでくるはずです。

f:id:ReaLiZeZNSG:20180715191547p:plain

hostはフォワーダをインストールしたサーバ(WS2012R202)、インデックスはデフォルト設定のインデックス(main)、ソースタイプは規定のものが使われるようです(Windowsイベントログのセキュリティだからこうなっていると思われる)。何だかスッキリしないのでもう少し設定に深入りしてみます。

設定ファイル

フォワーダの設定値はバイナリファイルに直接設定されるより、テキスト形式のconfファイルに書き込まれるケースの方が多いようです。とりあえず全体的な設定値は以下にフォルダに格納されます。

C:\Program Files\SplunkUniversalForwarder\etc\system\local

この中にoutputs.confというものがあり、私の環境では以下のような内容になっていました。


[tcpout]
defaultGroup = default-autolb-group

[tcpout:default-autolb-group]
server = 192.168.0.51:9997

[tcpout-server://192.168.0.51:9997]

 

 フォワーダのマニュアルによると、[tcpout]の下に書かれているdefaultGroupはこのフォワーダがログの送信先とするインデクサグループの名前のようです。この名前はデフォルト値とのことでした。カンマ区切りで複数のグループを指定することができます。複数指定すると全てのグループにログを送信するようになるそうです。

次に[tcpout:default-autolb-group]というものがあります。先程指定されていたグループ名に所属しているインデクサを具体的に指定するようです。カンマ区切りで複数のインデクサを指定できます。インデクサを複数指定すると今度は全てのインデクサにログが送信されのではなく、ロードバランスされるようです。ロードバランスアルゴリズムは分かりません。

最後に[tcpout-server://~]ですが、これは単一のインデクサを指定する場合に使うようです。マニュアルでも任意となっているので先程のグループ設定ができていれば不要と思われます。

余談ですが、グループ内でインデクサを複数指定した場合はロードバランスされるとのことでしたが、全インデクサにログを送信したい場合はグループを分けてそれぞれのグループにインデクサを1個ずつ指定すれば良いようです。

フォワーダapp

フォワーダインストール時にWindowsイベントログ等を取得するようにチェックボックスを入れました。本来、フォワーダは特定ファイルやフォルダを監視しログを送信する役割を果たすようですが、Windowsフォワーダの場合は特段イベントログを書き出さなくてもフォワーダがイベントログを読んでくれるようです。恐らくWMI経由なんだと思いますが。

フォワーダのマニュアルによると、これはフォワーダの拡張appのような位置づけとなるようです。これらの設定値が書かれたファイルが先程のパスにはなく、どこに書いてあるのだろうと探してみたところ、以下のパスにあるようです。

C:\Program Files\SplunkUniversalForwarder\etc\apps\SplunkUniversalForwarder\local

このフォルダにinputs.confというファイルがあり、フォワーダインストール時にチェックをつけた内容に関するパラメータが指定されているように見受けられます。例えばセキュリティイベントログの値です。

[WinEventLog://Security]
checkpointInterval = 5
current_only = 0
disabled = 0
start_from = oldest

 また固有のパラメータっぽいのがたくさんでてきました。フォワーダのマニュアルには説明が出てこなかったのでSplunkのサイトを巡ってみたところ、以下のURLに一覧がありました。

Monitor Windows event log data - Splunk Documentation

まあ大体見たままなのですが、一番知りたかった送信先インデックスはindexアトリビュートを使用することでやはり指定ができるようです。デフォルトでは、インデクサのデフォルトインデックスに送信することになっているようなので、上記で示した通りインデックスmainとなっていたというわけです。

そんなわけで、フォワーダの調査は結構長くなりそうなので今回はここで一旦区切ります。あと2,3回はフォワーダに関する話が続きそうな気がします。

書評 - 実践 CSIRTプレイブック セキュリティ監視とインシデント対応の基本計画

今週はゆっくりとSplunkの動作確認をしている余裕がないので今週は更新頻度が激低になってしまっています。

先日Interop2018に行った時に見つけて電子書籍で購入した本です。

実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画

実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画

 

 良書だと思います。Ciscoのセキュリティチームが書いた本で情報セキュリティ対策、実務の考え方が詳細に記載されています。しかし同時に一介の技術者には不向きとも言える内容です。この記事では本書の内容に触れつつもCSIRTにおける個人的な考え方を書いていこうと思います。本書ではインシデント管理プロセスを検討するにあたり中核となる4個の質問というものに言及しています。

  • 守りたいものは何か。
  • 脅威は何か。
  • どうやって検知するのか。
  • どう対応するのか。

保護対象の決定

一つ目の質問に自信を持って回答できる人はどれくらいいるでしょうか。全てと回答するのもアリですが、守る対象を全てと定めた場合は続く質問に対する回答を実現するために膨大なコストを覚悟する必要があるでしょう。しかし多くの組織では情報セキュリティ対策に投じることができるコストはそれほど潤沢ではないはずです。

私見ですが、ここで言いたいのは守るべき対象を真剣に定義することで、必要な対策とそのコストが明確になります。さらに現状取れる手段では守れないものが洗い出され、今後どう対策を取っていくのか議論することができるようになります。

守りたいものはを定義するには恐らく最低でも部長レベルの判断が必要になるはずです。あなたの組織のグループウェアには守るべき機密情報は含まれているでしょうか。ファイルサーバは?社員PCは?それらはどこにあるのか?上級管理職に許された特別な業務形態はないか?検討対象はたくさんあり、さらに一介の社員やマネージャレベルではアクセスできない機密情報が存在します。守る対象を決めないと対策の検討に移れないことが少し考えるだけで分かるはずです。

レポート

運用者にとってはレポートは非常に重要です。レポートの役割は単体のインシデントの詳細が記録されることは勿論ですが、後日に統計情報の入力ソースとして活用するという役割があります。情シスでは一定周期でのインシデント統計を報告する必要があります。そう考えるとレポートに格納されるべき情報が何であるかがイメージがついて来るのではないでしょうか。

報告を受ける人が最も気にするのは自分の組織に悪影響を及ぼす可能性のあるインシデントがあったかどうかです。例えば公開Webサーバを不正通信から保護するためにIPSを導入したとします。このWebサーバはApacheが使用されていますが特筆すべきミドルウェアなどは他に動作していません。その状態でIPSがTomcatの既知の脆弱性を突いた攻撃を検知しアラートレベルHighでログを出力したとしましょう。しかしこのWebサーバではTomcatは動作していないので特に影響のない攻撃です。

レポートに記載する内容はアラートレベルではなく組織に影響があるかどうかです。そのためIPSが記録したログを少なくとも影響の有る無しで分類する必要があります。さらにそのためにはログを見て影響の有る無しを判断するためのナレッジが必要になります。技術者はこの部分に特に注力し、必要なログを適切なレベルに分類する作業が必要になるでしょう。

様々な状況を示すコードが定義されレポートの定型が定まったら、次はレポート出力の自動化を目指していく形になります。(軽く書きましたが超大変な仕事です。一千万円ではきかないようなレベルの人材が必要と思われます。)実はここまでできてしまうとあとはレポート発行ツールの使い方の問題なので必要な知識レベルの質は大きく下がります。

インシデントの調査

本の中で具体的な脅威検出についてかなり言及しています。とは言え攻撃の一例なので、この内容を参考に色々なケースへの適用を考えていく必要があるでしょう。

例えばActiveDirectoryへの認証ログを考えてみましょう。ユーザ認証ログが残りその中に失敗があっても特におかしいことではありません。しかし認証に何度も失敗しているのがAdministratorアカウントだった場合はどうでしょう。もちろんパスワードを忘れて手入力を繰り返して失敗している可能性があります。しかしマルウェアブルートフォースアタックをしている可能性もあります。個人的にはこのケースでは5回連続失敗あたりからアラートを出すようにログサーバなどで仕掛を作っておくのが良いと思います。

IPS製品によってはこうした攻撃を検知してくれる可能性もありますが、必ずしも全てのサーバにIPSを仕掛けることが可能とは限りません。攻撃者の手法を学び、自分の組織に合ったセンサーを作っていく必要があります。

不幸にも攻撃と判断する基準を超える挙動が検知された場合はその挙動をした要素(大抵は端末のIPアドレスや利用者のユーザID)が他に何をしていたか調査することになります。まず見るのはファイアウォールトラフィックログやxFlowコレクタの状況だと思います。そこで見慣れない宛先と通信している場合はマルウェアに感染している、または内部不正を働いている可能性が急激に増加します。

重要なのは、自らの組織に導入されているセキュリティ装置やログ集積装置を使った調査シナリオを明文化しておくことです。これにより高レベルでないフォレンジック作業を手順化することができます。

情報セキュリティに関する体制作りに関心のある人は読んでみて損はないでしょう。丸投げ気質の人には多分有効活用できないですが、逆にこうした内容を読んで関心を持つ人もいるかもしれません。SI的な仕事をする人にもおススメします。システム構築の時にどのような管理設計を行うと客に喜ばれるのか、どのような機能を持つ製品が一連の流れに効果的に寄与できるのか、流れをスムーズに進めるにはどのようなログ基盤を作れば良いのか、参考になる点は多々あるはずです。