Loggolは有料であることに伴いサポートも存在するため、利用にあたって不明な点があれば質問する先があります。一方でiLogScannerには基本的にサポートは期待できないと思いますので（IPAに質問したときにどのくらいの回答がもらえるかは私にもわからないですが）、基本的に困った場合は自己解決する必要があると考える方がよいでしょう。

メンテナンスされているか

Loggolは正式版が2024年にリリースされたばかりの新しいサービスであり、当然ですがメンテナンスは行き届いている状態です。

一方、iLogScannerは2014年以降新しいバージョンがリリースされておらず、既にメンテナンスされていない状態であると言えるでしょう。Log4jに代表されるような比較的最近のウェブの攻撃には対応しておらず、検知することが出来ない状態になってしまっています。

稼働環境

Loggolはクラウドサービス(SaaS)であるため、ユーザはウェブブラウザやAPIクライアントを利用してログの分析を行います。PC環境にLoggol特有のソフトウェアをダウンロードしたりインストールしたりする必要はなく、環境の管理は不要です。

Loggolでは分析対象となるログはクラウドサービスに対してアップロードする必要があります。そのため、組織のポリシーによっては利用できない(外部にログを持ち出せない)ことがあったり、サービス利用のための許可を取り付けるなどの手間がかかったりするかもしれません。

iLogScannerはPC上で動作するので、ダウンロードして自身のPC環境で使う必要があります。このときJavaもインストールする必要があり、これも含めて環境の管理が必要になります。ログファイルはPC上に存在していればよいので、自社の管理下のコンピュータリソース内で利用が完結する点は魅力になるでしょう。

自動化への対応

定期的に（たとえば毎日など）ログを分析するようなケースでは、毎回Loggolにブラウザを使ってログをアップロードしたり、あるいは手元のPCにログを持ってきてiLogScannerを起動したりするのは、人的コストの面でなかなか辛いものがあります。

LoggolにはWebAPIの機能があるため、ウェブサーバなどで生成されたアクセスログをLoggol側にアップロードして分析し、その結果を受け取り、さらにその結果を他のDBに格納したりメールやSlackに通知するなどの処理をすべてAPIの利用により自動化することができます。APIが出力する分析結果のフォーマットとしてはJSONを採用しているため、他のプログラムがさらにそれを入力として処理することがやりやすくなっています。

一方、iLogScannerは基本的に分析結果をHTMLなどの『人が見ることを想定した』形で出力するため、さらに他のプログラムの入力とするにはパースする処理を開発する必要があり、敷居が高いです。

Loggol開発者の立場からは、Loggolは最終的にはぜひAPIを使う形に落とし込んで頂き、DevSecOps的な、自動化されたセキュリティログ分析の仕組みの中で使ってほしいと考えています。

検知精度

それほど厳密にはまだ比較していませんが、Loggolでは見つかる攻撃がiLogScannerで見つからないケースをかなり多く把握しています。しかし逆のケース(iLogScannerで検知したがLoggolが検知しない）もあるとユーザさんから指摘頂いたこともあるので、この点については調査し、必要な場合はLoggol側を継続的に改善していく予定です。

私が見つけている具体的なケースでは

Log4j
Struts2への攻撃としてよく知られているOGNLインジェクション
リスト型攻撃(ログイン総当り)
リコネサンス
リモートファイルインクルージョン(RFI)
サーバサイドリクエストフォージェリ(SSRF)
コードインジェクション

については、iLogScannerでは検知できないようです。また、iLogScannerの検知対象としてドキュメントに載っているコマンドインジェクションやパストラバーサルについても、Loggolでは検知できるが、iLogScannerでは見つからないパターンを多くデータとして確認しています。

False Positive(攻撃でないものを攻撃として検知してしまう)については、まだそれほどきちんと調べられていません。後日、調査できたらまたブログでお知らせしたいと思います。

分析速度

Loggolはクラウド上で比較的高性能のコンピュータリソースを使用しているため分析は速いと考えていますが、一方でiLogScannerもPCのCPUが高性能であれば、結構速いようです。この点はユーザさんの環境に大きく依存します。

攻撃成功の可能性についての言及

iLogScannerにはSQLインジェクションについては「攻撃が成功した可能性が高い件数」という出力をする機能があります。しかしLoggolでは2024年11月時点ではこれは実装していません。iLogScannerは「SQLインジェクションのペイロードが確認され、かつステータスコードが500になっている」という行について、攻撃が成功した可能性が高いと判定しているようです。

このロジック自体はシンプルなのでLoggolでも同じようにすることはもちろん可能なのですが、厳密にはSQLインジェクションは「攻撃が成功して、ステータスコードが200」の場合もありますし、「攻撃が成功して、ステータスコードが500」の場合もあります。そのため500の場合のみを攻撃が成功した確率が高い、とするのは何だか違うのではないか…と考えています。この機能を実装してしまうと、かえって200になっているSQLインジェクションについては「これはたぶん攻撃は成功していないんだな」という誤った安心感を与えてしまう気がしています。

また、ステータスコードが200でも500でも、攻撃が成功していない可能性も、もちろんあります。

一方で、基本的にステータスコードが500になるということ自体が異常なので、SQLインジェクションのペイロードがあるかどうかとは無関係に、そもそもログの中でステータスコードが500になっている行については原因を調査するのがよいと思います。

まとめ

今回はLoggolとiLogScannerを簡単に比較してみました。iLogScannerの最大の魅力は無料で使えるところです。一方で、iLogScannerは見つけられない攻撃が比較的多いという印象です。また、LoggolにはAPIがあるので、ログ分析の一連の処理を自動化できるところが利点となっています。二週間の無料トライアル期間がありますので、ぜひお気軽にご利用ください。

2024-11-13

Loggol アップデートのお知らせ(1.0.2)

Loggolをアップデートしました。今回はログ分析の部分の精度の向上です。SQLインジェクションを中心に、今まで検出できていなかったいくつかのパターンを検出できるようにしました。

Loggolは基本的にはWAF(Scutum)で鍛えた分析ロジックを基にしています。そのため、誤検知をなるべく起こさないような、やや慎重なチューニングになっていました。今回ユーザ様からフィードバックを頂き、検知できていないケースがあったため、より積極的に検知を行う方向に変更を行いました。

新しいバージョンは1.0.2となります。下図のように分析タスク一覧などにバージョン情報が表示されます。これが1.0.2になっている場合、更新されたバージョンでの分析が行われていることになります。

2024-10-24

Loggolの検知対象である「リコネサンス」とは何なのか

はじめに

Loggolはウェブサーバのアクセスログを入力とし、そのログに含まれる攻撃の情報を出力する超シンプルなサービスです。例えばSQLインジェクションやパストラバーサルなど、良く知られているウェブの攻撃が検知対象です。一覧表はこちらにあります。この中に「リコネサンス」というものがあるのですが、こちらは若干聞き慣れないものだと思いますので、こちらのブログで内容を紹介します。

リコネサンス=偵察

リコネサンス(Reconnaissance)は「偵察」「調査」などを表す言葉です。サイバーセキュリティの分野では「スキャン」に非常に近いニュアンスです。たとえばこちらのオライリーの書籍では、「Web application reconnaissance refers to the explorative data-gathering phase that generally occurs prior to hacking a web application」とあります。「本格的なウェブアプリケーションへの攻撃の前段階の探索的な情報収集」という感じです。

例えば、ターゲットにおいて「ある特定のWordPressのプラグインがインストールされているか？」を調べるようなアクセスが、リコネサンスの代表的なものになります。

リコネサンスにより使用されているソフトウェアの種類やバージョンを事前に把握しておくことで、攻撃者は今後そのソフトウェアに脆弱性が見つかったときに、即攻撃を実施するのかもしれません。

実際の例

では実際の例を見てみましょう。例えばあるIPアドレスからのアクセスが、下のような内容だったとします。

404 /api/message/webInfo
404 /auth/web/login/webLoginEwm
404 /html/wechat/getkey
404 /member/css/bindmobile.js
404 /Mg0a4/app/data.js
404 /pc/serverConfig.js
404 /api/index/indexconfig
404 /notice/unreadMsgCount
404 /assets/js/video.js
404 /Loading.png
404 /melody/api/v1/retgistercolumn/list
404 /ashx/getPlatParam.ashx
404 /api.php
404 /static/icon.png
404 /h5/static/icon/icon_hetong.png
404 /Public/m/js/yxMobileSlider.js

左の数値はステータスコード、右がリクエストのURIです。URIだけ見ると、それほどは違和感がないかもしれません。

しかし、それぞれの行のトップの階層(/api/や/auth/など)がバラバラなのは少し不自然です。また、ステータスコードが全部404なのは、明らかに異常です。

これらはファイルの有無を知るための悪意あるアクセスです。単体で、このアクセス自体では被害は出ないものの、明らかに好ましくないものです。Loggolではこのようなアクセスを行うIPアドレスを検知し、リコネサンスとして出力します。

もう一つ、別の例を見てみましょう。

404 /admin/assets/upload_image.php
404 /assets/upload_image.php
404 /sites/all/libraries/elfinder/connectors/php/connector.php
404 /sites/all/libraries/elfinder/src/connectors/php/connector.php
404 /theme/assets/upload_image.php
404 /wp-admin/admin-ajax.php
404 /wp-content/plugins/1-flash-gallery/readme.txt
404 /wp-content/plugins/Tevolution/tmplconnector/monetize/templatic-custom_fields/css/jquery.lightbox-0.5.css
404 /wp-content/plugins/acf-frontend-display/js/blueimp-jQuery-File-Upload-d45deb1/js/main.js
404 /wp-content/plugins/advanced_file_manager_5/php/connector.minimal.php
404 /wp-content/plugins/aviary-image-editor-add-on-for-gravity-forms/includes/upload.php
404 /wp-content/plugins/dzs-zoomsounds/admin/upload.php
404 /wp-content/plugins/fluid_forms/file-upload/server/php/
404 /wp-content/plugins/formcraft/file-upload/server/content/upload.php
404 /wp-content/plugins/formcraft/file-upload/server/php/
404 /wp-content/plugins/formcraft/file-upload/server/php/upload.php
404 /wp-content/plugins/front-end-editor/lib/aloha-editor/plugins/extra/draganddropfiles/demo/index.css
404 /wp-content/plugins/pica-photo-gallery/css/style.css
404 /wp-content/plugins/secure-file-manager/vendor/elfinder/php/connector.minimal.php
404 /wp-content/plugins/sexy-contact-form/includes/fileupload/
404 /wp-content/plugins/simple-ads-manager/css/jslider.round.plastic.css
404 /wp-content/plugins/simple-forum/resources/jscript/ajaxupload/ajaxupload.js
404 /wp-content/plugins/super-interactive-maps/sim-wp-admin/pages/manage-maps.php
404 /wp-content/plugins/superlogoshowcase-wp/sls-wp-admin/pages/exportAjax.php
404 /wp-content/plugins/superstorefinder-wp/css/ssf-wp-pop.css
404 /wp-content/plugins/uploader/uploadify/uploadify.css
404 /wp-content/plugins/videowhisper-video-conference-integration/vc/flash_detect_min.js
404 /wp-content/plugins/videowhisper-video-conference-integration/vc/vw_upload.php
404 /wp-content/plugins/videowhisper-video-presentation/vp/translation.php
404 /wp-content/plugins/videowhisper-video-presentation/vp/vw_upload.php
404 /wp-content/plugins/wp-file-manager-pro/lib/php/connector.minimal.php
404 /wp-content/plugins/wp-file-manager/lib/php/connector.minimal.php
404 /wp-content/plugins/wp-front-end-repository/js/uploadify/uploadify.css
404 /wp-content/plugins/wp-mailinglist/css/colorbox.css
404 /wp-content/plugins/wp-property/third-party/uploadify/uploadify.css
404 /wp-content/plugins/zingiri-web-shop/fws/addons/tinymce/jscripts/tiny_mce/plugins/ajaxfilemanager/ajaxfilemanager.php
404 /wp-content/themes/qualifire/scripts/admin/uploadify/uploadify.css

こちらはWordPressのプラグインを中心に探しています。パッと見た感じは悪意があるように見えないのですが、ステータスコードが全部404であることや、巧みに特定のjsやcssのみでプラグインインストールの有無を探っていることから、間違いなく悪意のあるアクセスであると考えることができます。

WAFで見つけにくい

私はLoggolの開発者であると同時にクラウド型WAFのScutumの開発者でもあり、WAFを使って検知・防御する立場でもあります。しかしこのリコネサンスについては、なかなかWAFで見つけるのは難しいです。というのも、WAFはリクエスト単体が届いたらその時点で「これは攻撃か?」と考える必要があるからです。

リクエストが届いた時点では、それはごく普通のGETリクエストに見えてしまいます。特にスタイルシートへのアクセスなどは、本当にありふれたものです。レスポンスのステータスコードが404になるかどうかはWAFがリクエストを受け取った時点ではわかりませんし、また仮に404だったとしても、それが単なるリンク切れやファイルのアップロード忘れである可能性も考慮する必要があります。

一応、WAFでリコネサンスを検知するために考えられる方法としては、あるIPアドレスからのアクセスをしばらくの間記憶しておく(いわば、文脈を残しておく)ことで、404連発のアクセスを行うIPアドレスを「怪しい」と考え、一連のアクセスの後半においては、攻撃と判定することはできるかもしれません。しかしその場合であっても、最初のいくつかのアクセスは見逃してしまうことになるでしょう。ストリーミング処理とも言えるWAFでは、リコネサンスの検知はなかなか厄介です。

Loggolのような攻撃ログ分析ツールでは幸いにも「全部揃っている状態」からの分析ができます。こちらはいわばバッチ処理とも言えます。じっくりと全ての情報を見回してから攻撃かどうかの判定を下すことができるのです。この点はWAFに対するアドバンテージになります。行ったアクセス全体を分析の材料にできるので、リコネサンスについては検知がしやすい面があります。

一方、WAFはWAFで、POSTリクエストのボディ部や、各ヘッダの内容を判断材料に出来るため、単発のアクセスで成立する攻撃についての検知能力はとても優れています。

検知件数は多い

リコネサンスは非常に多く実施されています。そのためLoggolでアクセスログを分析してみると、最も多く検知されるのがリコネサンスである場合がよくあります。それ自体では被害が出る可能性は低いですが、どのくらいリコネサンスが行われているのかを把握しておくと、管理しているウェブサイトにおけるセキュリティの温度感みたいなものが把握できるかもしれません。

まとめ

今回はLoggolが検知する攻撃のうちのひとつ、リコネサンスについて概要を紹介しました。先に上げた例の他に、単なる.envファイルを探すアクセスなども、リコネサンスとして検知します。

WAFでは見つけにくい種類の悪意あるアクセスであり、かつ件数も多いです。Loggolではまずまずの精度でこれを見つけられます。二週間は無料でトライアル出来ますので、ぜひ試してみてください。

このブログに関する質問などはお気軽に@kinyukaまで。

2024-10-01

Loggolというサービスを作った理由

はじめに

ついにLoggol(ロゴル)の正式版をリリースすることが出来ました。それに合わせてLoggolブログも開始です。まず最初の記事として、そもそも何故このサービスを作ったのかについて書いてみようと思います。理由は複数あり、それらが複合的に混ざることで実際のサービス化を決心しました。

1. WAFの技術を活かせる

私はLoggolの開発以前より、継続して2つのクラウド型のセキュリティサービスの開発・運用に携わってきました。1つはWAFであるScutum、もう1つは脆弱性検査ツールであるVAddyです。どちらもおかげさまで順調にユーザを獲得でき、軌道に乗っています。

前者はWAFなので、受け取ったHTTPリクエストのデータを見て、それが「攻撃かどうか」を判断するという部分がサービスの中核になります。これはソフトウェアによって瞬時に行われる処理であり、人が判断するヒマはありません。ウェブアプリケーションセキュリティの知見を持った人間が自身の知識をソフトウェアに落とし込み、自動的に「攻撃かどうか」を分類することが可能なソフトウェアを作ることによって、WAFを作ることができます。

WAFは通信の途中に割り込んで上記の分類を実施し、「これは攻撃だな」と判断したらその通信を止めます。これによってWAFに期待されるリアルタイムな防御が可能になります。ここでWAFが行っているのは

攻撃なのかどうかを分類する
もし攻撃と判断したら、その通信を止める

という2点なのですが、実は2はとても簡単です。HTTPのレスポンスをステータスコード403で返してもよいですし、単にソケットを閉じるだけでも良いです。ここには技術的な難しさはありません。難しいのは1です。多種多様なデータが送られてくるウェブアプリケーションの入力に対して、高い精度で「攻撃かどうか」を分類する必要があります。

Scutumではベイジアンネットワークという技術や単なる正規表現のパターンマッチング（シグネチャと呼ばれる）などを組み合わせてこの分類性能を高めています。そして高い分類性能によって、WAFとしてよい仕事ができるよう改善を重ねてきました。

この「攻撃かどうか分類する」ソフトウェア機能は、WAF以外にも出番があります。例えばWAFに非常に似たIDSやIPSがあります。また、SIEMでも同じように、集められたログなどの情報に対して「攻撃かどうか」を分類するためにソフトウェアが機能します。

WAF/IDS/IPS/SIEMは既に非常に良く知られたセキュリティソリューションとなっています。さらに他にこのような分類機能が役に立つ場面はないだろうか？と考えると、IPAが出しているiLogScannerが思い浮かびます。これはウェブサーバ等のアクセスログを入力データとしており、それぞれの行を「攻撃かどうか」分類することで、アクセスログの中から悪意ある攻撃を抽出するものです。WAFとは異なり分類が行われる時点はリアルタイムではありませんが、ソフトウェアの機能はほぼ同じものです。このiLogScannerのような形態を以下では「Web攻撃ログ分析ツール」あるいは単に「ログ分析ツール」と呼ぼうと思います。ログを分析するという点ではSIEMに似ていますが、ウェブのアクセスログに限定した、非常にシンプルな立ち位置です。

iLogScannerが登場した当時から、私の頭の中では「これはWAFとほぼ同じ仕組みだ」と感じており、自分たちでも作れそう…というイメージは、もうずいぶん長い間持っていました。そしてWAFサービスを運用・開発していく中で、開発で使用する品質担保のためのテストコードの中には実質的にWeb攻撃ログ分析ツールそのものと言える物も存在しており、あとはビジネス的な枠組みを整備すればサービス化できる状態になっていました。

このように、必要とされる中核部分の技術はWAFとログ分析ツールで共通であるということが、1つめの理由です。

2. ログ分析ツールも優れた形態である

2つめの理由として、iLogScannerのスタイル、つまりログ分析ツールという形態はWAF/IDS/IPS/SIEMとは異なったメリットを持つという点があります。とりあえずIPS/IDS/SIEMは除外して、WAFとWeb攻撃ログ分析ツールの比較をしてみましょう。

WAFの最大の魅力は攻撃を止めてくれることでしょう。ログ分析ツールはWAFとは異なり事後に分析を実施するので、攻撃を止めることはできません。この一点だけで考えても、基本的にWAFが非常に優れたソリューションであると思います。

一方で導入コスト(特に人的なコスト)について考えてみると、ログ分析ツールの圧勝になります。単にアクセスログさえ用意できれば、すぐに使うことができます。

また、ログ分析ツールの導入では既存の情報システムに影響や副作用を与えないことも大きなメリットです。WAFの場合は通信に割り込む必要があるので既存のシステムに大きな変更を加える必要があります。また、WAFでは誤検知すると正常なビジネスの妨げになります。一方でログ分析ツールはアクセスログを取り出してしまえば、そこから先は既存のシステムから切り離された場所でのんびり使うことができます。また、ログ分析ツールでは誤検知があってもそれが正常なビジネスに与える影響はありません。この「手軽さ・気軽さ」はWeb攻撃ログ分析ツールの最大の利点と言えるでしょう。

さらに、WAFの強さはリアルタイム性ですが、逆に過去の古いデータをさかのぼって、例えばWAFを導入する前の古い通信やログについてはWAFを適用して攻撃を見つけることはできません。一方でログ分析ツールはかなり昔に取得したアクセスログでも、あるいは生成された直後のリアルタイムに近いログでも、どちらも問題なく分析することができます。

このように「攻撃を止めることはできない」ログ分析ツールにも、優れた点があるのです。そのためWAFのサービスを既に提供しており、前節で述べたように「攻撃かどうか」を分類できるソフトウェアを持っている私達としては、WAFに加えて別の形態としての「Web攻撃ログ分析ツール」を提供することにも意味があると考えました。

3. ベターなiLogScannerを作りたい

個人的にiLogScannerはとても良いサービス・ツールであると思いますが、やはり公的な機関から提供されるという立て付け上、いくつかの課題があると考えています。その中で最も気になるのは最終更新が2014年、つまりほぼ10年前であるという点です。そのため、Log4jのような、ここ数年で新たに登場した攻撃については検知することができません。

また、無償で使える反面、サポートについても実質的に提供されないでしょう。基本的には使う側のリテラシーをそれなりに要求するツールであると思います。

さらに、iLogScannerは基本的にデスクトップアプリケーションであるため、アクセスログを定期的かつ自動的に取得し、それらを分析して結果を継続的に監視していくような仕組み（いわゆるDevSecOps）を組み立てるのは難しいと考えられます。LoggolではWeb攻撃ログ分析ツールをクラウド型のサービスとして提供し、さらにWebAPIを用意することで、これを可能にしています。

このように「iLogScannerはとても良いツールだが、よりベターなものを提供できそうだ」というのが3つめの理由です。

4. WAFとは違う分析が可能

先述した「2. ログ分析ツールも優れた形態である」ではWAFとログ分析ツールの比較をしました。そこでは主に導入や運用面でのログ分析ツールの強みを解説しましたが、本来の目的である攻撃の発見という点においても、ログ分析ツールにはWAFでは実現できない分析が可能である場合があります。

WAFは「今そこに届いた」データを相手に短時間で処理して結論を出す必要があるため、多くのデータを参考にしてじっくり時間を欠けて分析することはできません。一方でログ分析ツールは数万行や場合によっては数百万行あるような大きなログの全体を見つつ、部分を評価する、いわゆるビッグデータ分析のようなことが可能です。これによって異常検知なども可能となってくるため、WAFでは発見できない攻撃や異常に気づくことができるケースがあります。

（一方で、通常アクセスログにはPOSTリクエストのボディ部が記録されていないため、単純にボディ部に含まれる攻撃はログ分析ツールでは発見することができません。この点ではWAFが完全に優れています。攻撃発見における両者の違いとして非常に大きなポイントなので、ここに記しておきます。)

このようにログ分析ツールはリアルタイム性がないからこそ時間をかけた分析ができるという点をWAFに対するアドバンテージとして利用することが出来ます。Loggolでは異常検知の機能を提供しています。今後もこの点を活かして、より高度な分析が可能となるようにLoggolを進化させていきたいと考えています。

5.その他

主な理由は上記の4点なのですが、他にも細かい点がいくつかあります。簡潔に書くと

ログの分析はパスワードリスト攻撃の検知に非常に便利である
セキュリティのためのログ分析入門という本を見て、この分野のニーズを感じた
VAddy(脆弱性検査)で事前に備え、Scutum(WAF)でリアルタイムに防御し、そしてLoggol(ログ分析)で事後を固めるという形で、時系列の広い範囲でウェブセキュリティのサービスを提供したい

となります。

まとめ

今回は「なぜLoggolというサービスを作ったのか」という点について、中心となる4つの理由を書かせて頂きました。シンプルで使いやすいサービスを目指していきたいと思っていますので、どうぞよろしくお願いします。

Loggolについてのご意見・ご要望などお気軽に金床までお伝えください。

2024-09-24

準備中

現在ブログの準備中です。