今回の内容は前編として公開した以下記事の後編となります。まだ前編をご覧いただけていない方は先に前編からお読みいただくことをお勧めします。
前編では、EasyBlocks SyslogのWeb UIにおけるログイン失敗時のログの特徴を分析し、「POST /system/login.php に対して200が返ってきたらログイン失敗」という監視の判断基準を出しました。
後編となる今回は、実際にEasyBlocks SyslogとZabbixを使って、そのログイン監視を設定・実践していきます。
はじめに
まず今回使用する構成と実践内容を整理します。
使用する機器と実施する設定
EasyBlocks Syslog(ver1.2.1)
・自身のログ受信設定
・Zabbixサーバー連携機能の設定(Zabbix用ホスト登録、Zabbixトラッパー連携条件設定)
Zabbixサーバー(ver6.0.42)
・ホストの作成
・アイテムの作成
・トリガーの作成
確認内容は以下の通りです。
EasyBlocks SyslogのWeb UIアクセスに関して、1分以内に5回以上のログイン失敗を実際に再現し、Zabbixサーバー側で検知・通知されるかを確認します。
設定
Zabbixサーバー側
設定の順番としてはEasyBlocks Syslog側より先にZabbixサーバー側を済ませておく必要があります。
EasyBlocks Syslogから該当ログを送る先となるホストやアイテムが、Zabbixサーバー側にあらかじめ存在していないと受け取れないためです。
ホストの作成
今回は必要最低限の①ホスト名、②グループのみ設定します。
アイテムの作成
アイテムの種別はZabbixトラッパーを選択します。EasyBlocks Syslogは該当ログをZabbixトラッパーアイテムに向けて送信します。
設定内容はシンプルで、①アイテムの名前、②タイプ、③キー名を設定するだけです。
トリガーの作成
今回のトリガー式は以下の通りです。
count(/ホスト名/アイテムキー,1m,”like”,”POST /system/login.php HTTP/1.1\” 200″)>=5
作成済みのホスト、アイテムを当てはめると以下の形式になります。
count(/216syslog/webui,1m,”like”,”POST /system/login.php HTTP/1.1\” 200″)>=5
count() 関数で過去1分間(1m)に対象の文字列を含むログが何件届いたかを集計し、5件以上(>=5)でトリガーを発火させます。
トリガーの設定箇所は、①トリガーの名前、②条件式のみです。
EasyBlocks Syslog側
自身のログ受信設定
EasyBlocks Syslog自身が出力するアクセスログを受信するための設定です。自分自身のログを自分自身に送る形になりますが、これによりWeb UIへのアクセスログが監視対象として扱えるようになります。
設定箇所はサービスの基本タブにある①自ホストのsyslogを受け取ると設定するのみです。
Zabbixサーバー設定
連携先となるZabbixサーバーのIPアドレスとポート番号を登録します。
Zabbix用ホスト登録
Zabbixサーバー側で登録したホスト名、アイテムキー情報を登録します。
設定箇所は予めZabbixサーバー側で登録した①ホスト名、②アイテムキーのみです。
Zabbixトラッパー連携条件設定
どのようなログをZabbixサーバーへ転送するかの条件を設定します。
今回は POST /system/login.php を含むログを転送対象とします。
設定箇所は①ログ送信元ホスト名(IPアドレス)、②メッセージ内容、③ホスト名、④アイテムキーです。
動作確認
設定が完了したら、実際にログイン失敗を再現して動作を確認していきます。
1. ログイン失敗を5回再現する
EasyBlocks SyslogのWeb UIへブラウザでアクセスし、わざと誤ったパスワードを入力してログインを5回失敗させます。この際、1分以内に5回の操作を行うことがポイントです。
2. EasyBlocks Syslog側でログを確認
まずEasyBlocks Syslog自身のログ表示画面で、該当のアクセスログが正しく記録されているかを確認します。
ログが5回分、正しく記録されていることが確認できました。
3. Zabbixサーバー側で最新データを確認
次にZabbixサーバー側で、該当のZabbixトラッパーアイテムの最新データにログが届いているかを確認します。EasyBlocks Syslogから正常に該当ログが送信されていれば、ここに表示されるはずです。
4. 障害画面でトリガー発火を確認
Zabbixの障害画面を開き、設定したトリガー条件通りに障害として判定されているかを確認します。
5. 通知
通知に関してはメール、Slackなど様々な方法がZabbix側にありますので本トリガーを利用して通知可能です。
今回はメール通知と紐付けていたので以下のようなメールを受信しました。
まとめ
今回は、EasyBlocks SyslogとZabbixを組み合わせて、Web UIへのブルートフォースアタックを想定したログイン監視を試しました。
現時点ではEasyBlocks Syslogにブルートフォースアタックに対するアカウントロックやアクセスブロックといった機能は実装されていませんが、「検知して通知する」という仕組みを作ることで、管理者がいち早く異常に気づいて対応できる環境は今すぐにでも整えられることがわかりました。
完全に防ぐことはできなくても、気づける状態にしておくことはセキュリティ対策の第一歩として十分に意味があると考えます。
今後のアップデートでより厳密なセキュリティ機能が実装されていくかと思われますが、それまでの間はこのような運用でカバーしていくのが現実的な対応ではないかと思います。
後日談
子供のiPhoneに関して後日談がありまして・・・。
スクリーンタイムのパスワードを入力すると親にバレるということを学習したのは間違いないようで、その後はパスワードを試みる通知は来なくなりました。
数日後、ふと自分のスマホからスクリーンタイムを確認してみると、本来触れないはずの時間帯に使用履歴が残っていました。
さらにアプリごとの使用状況を確認してみると、デフォルトの電話アプリとメッセージアプリの使用履歴が。
はい、、そうです。スクリーンタイムのデフォルト設定では、緊急時の連絡手段を確保する目的で、電話アプリとメッセージアプリは休止時間の対象から除外されています。どうやらそこに気づいて、休止時間になったらそれらアプリを使っているようでした。
とはいえ何らかの緊急時にこれらアプリが使えないのは困るので、一旦様子見としました。