こんにちは。ネットワールドの大谷です。
本稿は「Predictive Alin AIとMetaDefender Aetherの検証レポート ～脅威ファイル検証編～」の続きとなります。
今回は、ログ解析やトラブルシュートの検証について紹介していきます。
■Aetherのログについて
AetherはDocker上で動作しており、障害調査時にはどのコンポーネントで問題が発生しているかを切り分けることが重要です。
主なコンテナは以下の通りです。
- Webservice：プラットフォームのフロントエンドインターフェース（WebUI）
- Transform：ファイルのスキャンと解析を実施するエンジン
- broker：WebserviceとTransformを仲介する
ログはそれぞれ/home/sandbox/sandbox/logsに格納されております。
- Webservice.json：WebUIが応答しない場合などの調査
- transform.log：スキャンの失敗やタイムアウト、ジョブの処理不良での調査
- broker.log：WebUIとtransformが正常で、且つスキャンが失敗している場合やコンポーネント間の通信に問題がある場合の調査
なお各ログは、UTC時間のため、JST時間を知りたい場合は+9時間する必要があります。
■コアログとAetherのログからSSRF対策のログが見れた
MetaDefender CoreのログとAetherのログで両サーバが疎通しているか確認したところ、以下ログを確認しました。
[{flow_id=6a0a830eb9b9d26ffd7f88b2, uid=9cac5762-eefd-4f43-ae5a-4b209e7c5236}] pool-6-thread-12 2026-05-18 03:10:36,443 WARN 76 [UrlRestrictionFilter] - Download blocked, as the given URL "http://10.16.166.10:8008/#/public/filescan/dataId/58bc66d5628d4766a31f73d49d835e6b" resolves to a private IP address.
初めてこのログを確認した際は、以下のように考えました。
- MetaDefender CoreとAetherの通信に問題が発生しているのではないか
- AetherがCore上のファイルを取得できていないのではないか
つまり以下のような状態が発生しているのか？
実際にメッセージだけを見ると「Download blocked」と出力されているため、ファイル取得処理そのものがブロックされているように見えます。
しかし、解析を進めると、原因は通信障害ではなくAetherのSSRF対策機能によるものでした。
※SSRF：Server-Side Request Forgeryの略。Webアプリがユーザから受取ったURLにアクセスする機能を持っている場合に、攻撃者が悪意のあるURLを指定して、サーバ自身に意図しない通信をさせる攻撃手法のこと
そのため、Aetherでは内部IPアドレス宛てのアクセスを制限し、SSRF攻撃に利用される可能性を低減しているものと考えられます。
今回の調査では一見すると通信エラーにも見えましたが、実際には製品が備えるセキュリティ保護機能による正常な挙動でした。
SandboxのURLの解析結果も未定という結果になっておりました。
■AetherのWebUIポート変更
最後にAetherのWebUIポートを変更したらどのような影響があるのかを検証しました。 WebUIのポート自体は以下マニュアルの手順で変更が可能です。
まず、"/home/sandbox/sandbox/webservice/docker-compose.nginx.yml"をviエディタで以下のように編集します。
※赤枠を編集します。
※必ず左側の数値を編集してください
ポートを変更しましたら、保存してviエディタを閉じます。 閉じましたら、Aetherのサービスを再起動します。 再起動はスクリプトが用意されておりますので、そちらで再起動してください。
再起動スクリプト：/home/sandbox/sandbox/restart_sandbox.sh
問題なく再起動ができれば、設定は完了です。 設定したポート番号でAetherのWebUIにアクセスします。
では、スキャンしてみます。
スキャンしてみるとFailed to ProcessでAdaptive Sandboxが失敗しました。
Adaptive Sandboxの欄をクリックし、詳細を確認したところ「Network error occurred during file upload: Could not establish connection」とのことでエラーが発生していた。 接続が確立できない？
Aether側のポートを変更した場合は、MetaDefender Coreに登録しているAetherの接続先URLも変更後のポート番号へ修正する必要があります。
MetaDefender CoreにてAetherのポートを明示的にすることにより、MetaDefender CoreがAetherを認識し正常に解析をしてくれました。
まとめ
全3回にわたり、2026年6月に国内リリースされたPredictive Alin AIおよびMetaDefender Aetherの検証を実施しました。
第1回ではAlinおよびAetherの概要から導入方法、MetaDefender Coreとの連携手順について紹介しました。
第2回では古いインストーラファイルやフィッシング訓練メールを用いた検証を行い、Aetherによる振る舞い分析やURLレンダリング解析の結果を確認しました。
そして第3回となる本稿では、Aetherのログ構成やトラブルシュート時の確認ポイントを整理するとともに、SSRF対策によるログ出力やWebUIポート変更時の挙動について検証しました。
今回の検証を通じて、AlinはAIを活用した高速な予測型検知エンジンとして利用できることを確認できました。また、Aetherについては従来のサンドボックス解析に加え、LLMを活用した分析結果を提供することで、セキュリティ担当者が脅威内容をより把握しやすくなっていると感じました。
特にファイルベースの脅威対策やフィッシング対策、未知の脅威に対する分析を強化したいお客様にとって、有効な選択肢の一つになるのではないでしょうか。
本記事が、AlinおよびAetherの導入や検証、運用を行う際の参考になれば幸いです。
最後までお読みいただき、ありがとうございました。
