2018localYouser技術のお話しログ解析が面白い前回の記事でElasticsearchを使ったRouterboardのFirewallのログ分析基盤を作ってみたのですが、いざKibanaを使ってDiscoverやVisualize、Dashboardなど触ってみると、色々情報が整理できて面白いなということを知りました。そこで、今回は様々なログを収集・分析し、いろいろな通信を把握することを試みてみました。主なネタとしては以下のような内容です。VPNルーター(RTX-3000,RTX-1100)のログ分析RTX-3000は本番拠点のVPNルーターです。このルーターでは、Mastodon本番インスタンスである(social.bluecore.net)のゲートウェイを兼ねています。これまでこのインスタンスに対する通信状況は、時々sidekiqを見るぐらいしか行っておらず、果たしてどのぐらいの通信が発生しているかを捉えられていませんでした。RTX-1100は災対拠点のゲートウェイルーター兼拠点間ルーターです。このルーターは災対拠点の拠点間ルーターであると共に、外部インターネットに対する境界ルーターでもあります。全体の通信把握ができてないのと、外部接続/内部接続の比率がわからないという課題が有りました。ASM->origin(2台)と言う通信経路でつながっています。この時、CloudFlareとWAF間の疎通に関しての通信把握が困難であるという課題が有りました。Firewallのログビューアが使いこなせないことに有り、WAFの通信のみ抽出し、どのバーチャルサーバにどれだけの通信トラフィックがあるかを押さえたいという思いがありました。IPv6中継ルーターのログ分析Homenocとの接続はRouterboardが担保しているのですが、実際に内部とのアクセスを中継・制御しているのは基本的にVMで動作するSEIL/x86です。こちらのACL状況を把握する必要があり、併せてブログやMastodonインスタンスのIPv6通信状況もこちらを通じて把握する必要がありました。構成コンポーネントの構成としては、従来のものをそのまま踏襲します。修正を行う必要があるのは、以下のようなポイントです。RAMに増強をしました。ログ収集設定の追加ログ収集対象が増えるため、設定ファイルを追加します。logstashの特性により、いくつか配慮する事項があるため、既存のRouterboard用設定ファイルも修正を加えます。JVMのメモリ使用量設定を修正します。多くのメモリを確保し、多くのデータ処理に耐えられるよう構成します。Elasticsearch、logstashのメモリ使用量設定修正いずれもJavaを使うため、JVMのメモリ設定が必要です。私の環境では以下の通りとしました。今回は以下のファイルを追加しています。SEIL/x86用収集設定そのウチの一つであるyomogi.confの設定を以下の通り表記します。}}ここで重要なのは、以下の部分です。}}typeと言う変数を定義し、それが何であるかを指定します。filterおよびoutputセクションでif分岐をさせています。filterセクションでは以下のように。{outputセクションでは以下のようにしています。配下のすべてのファイルを自動的に読み込んでログ収集処理を開始するようなのですが、設定自体はファイル単位に分かれてるわけではなく、logstashとしては一つにマージして動いてしまうようです。よって、このようにtypeを定義し、コレを用いてif分岐をさせないと、個別の設定が効かないようです。そのため、既存コンフィグであるrb2011.conf(Routerboard用収集設定)も同じロジックに基づいて修正しています。WAFのログ収集設定WAFのログ収集設定であるblog.confの中身は以下のようにしています。}}これは、以下点に留意しています。NATをした通信ではvserverフィールドに格納する情報がないので、NATされた情報に対してvserverフィールドにブログの仮想サーバFQDNを追加するgeoipを使って、そのIPアドレスがどこの国のものなのかを抽出し、データとして投入するuseragentの詳細情報を収集するこれらについて、順を追って説明しようかなと思います。GREEDYDATAによる複数項目読み飛ばしまず、WAFの出力ログの例を書いておきます。fw_rule_id=13コレに対するマッチングパターンはこうしています。fw_rule_id=%{NUMBER:ruleid}"ログ例にある太字箇所が「これはいらない」と判断した箇所で、そこを複数項目に渡って「GREEDYDATA」として取り扱い、変数定義しないことでElasticsearchの登録対象からまるっと外すことが可能となりました。して、マッチングパターンの文字数を少なくすることが可能になります。フィールドの追加・値の投入grokでマッチした文字列や値をフィールドへ放り込むのは以前の記事でも書いたのですが、そこにない値、例えば「このパターンに合致したログにフラグを付与したい」という場合、フィールドを追加して、文字列や数値を組み込むことが可能だったりします。}(以下略)流れとしては以下のような感じです。取り込まれたログはWAFログパターンと照合されます。該当すれば、IPv4で受け付けたアクセスになるので、ipversionと言うフィールドに4と言う値を放り込みます。該当しなければ、tagsフィールドに「_grokparsefailure」というメッセージが付与されます。引き続き、処理された情報のtagsフィールドに「_grokparsefailure」というメッセージが付与されているかどうか確認します。付与されている場合、NATログパターンと照合されます。照合した場合、tagsフィールドの「_grokparsefailure」は消去されます。ipversionと言うフィールドに6と言う値、vserverと言うフィールドに「www.bluecore.net」を付与します。該当しなければ、tagsフィールドに「_grokparsefailure」と言うメッセージが付与されたままになります。これにより、IPv4とIPv6、どのようなデータが来てるかを振り分けられるようになります。無駄なデータを読み込まない何れのパターンにも当てはまらなかった場合、tagsフィールドに「_grokparsefailure」と言うメッセージが残ったままとなり、必要最低限のフィールドしかもたない・・・けれども、クソ長いmessageフィールド値を持ったレコードが爆誕します。ファイアウォールのログ量というのは中々強烈で、コレをまともにElasticsearchに取り込んだらリソースがいくらあっても足りません。それらは取り込まないようにします。}geoipによる国情報を取得logstashにはgeoipと言う処理を使って、IPアドレスがどこの国に属するのかを調べ、データに追加することが可能なようです。dropされずに出てきたデータに対してこの処理を実施します。}useragentの詳細化useragentそれ自体が結構きちんとしたブラウザ情報を提供してくれていますが、より直感的に詳細の情報をデータに追加することが可能なようです。既存情報のフィールドを上書きするのは避けたいため、別名のフィールドを構成し、そこに情報を格納するようにします。}Kibanaなりを使用してデータ取り込み状況を確認する完了したら、logstashを再起動し、Indexパターンを登録した上でDiscovery画面を開きます。取り込んだログが正常に分類されているかどうかを確認します。後は・・・・Visualizeでグラフ作成などを行い、Dashboardを作れば、それなりの可視化が出来るようになりますし、細かい所はDiscover画面でサーチできるようになり、分析が比較的楽になると思います。geoipで世界地図にアクセス状況を出すのとか、何だかちょっぴりかっこよく、それっぽい感じになりますね。Analyticsを使ってある程度掴むことができていたんですが、自宅側のオリジンサーバに対するアクセスについては、コレを使ってある程度把握できたんでよかったなぁーって感じです。コマンド負荷状況ですが、こんな感じになってます。logstashの起動時が一番CPU負荷が高く、%CPUが395ということで、4vCPUをほぼ全部使い切ってました。最初の起動がすぎれば、その後はだいぶ負荷が下がります。その後もログは流れ続けるので、CPU使用率は10%前後をキープするという感じになっています。大規模環境で大量のログを集積するサーバなどは、この辺りのCPUチューニングが必要なのかなと感じています。参照系コマンドですが、以下のものが非常に便利でした。インデックス一覧の表示コマンドとしては以下のとおりです。<ElasticsearchのIP>:<ポート>/_cat/indices?v出力結果はこんな感じになります。件数や容量もわかるので、かなーり便利です。配下に溜まるみたいです。インデックスの削除コマンドとしては以下のとおりです。'http://<ElasticsearchのIP>:<ポート>/<削除するインデックス名>'インデックス名の指定はワイルドカードとか使えます。私の場合、途中で構成を見直して取り込み直しをしたり、Elasticsearchの中身を整理したかったりなど色々あったため、この削除コマンドはすごく役に立ちました。Elasticsearchに関して当初は全く興味がなく、「一体何をそんなに盛り上がってるんだろう?」的な気分でみていたものですが、ハマると面白いなーと思います。ログ分析とかを手作業でやって死にそうになってる人は、一度こういうのをやってみると良いかもしれません。logstashは先の記事でも書いてるように、logstashとしてはstdinから取り込むようにして、外部からもってきたログファイルをcatしてインポートすることにより、Elasticsearchで分析するということもできたりするので、色々応用が効くんじゃないかなと思います。