maltrail v2.2
公開ブラックリスト、静的マルウェアトレイル、ヒューリスティック分析を活用し、DNS、HTTP、IPトラフィックにおける脅威を識別するリアルタイム悪意トラフィック検出システム。
Maltrail
Maltrailは、既知の悪性インフラストラクチャとの通信を識別し、選択されたトラフィック異常を報告するネットワークトラフィック検出システムです。ネットワーク上で観測されたドメイン、URL、IPアドレス、IP:portペア、およびUser-Agent値を、_trails_と呼ばれるインジケータのセットと照合します。
検出は、送信元、宛先、プロトコル、一致したtrail、分類、およびtrailソースを含む単一のイベントとして記録されます:```text "2026-08-07 09:14:22.117034" gw 10.13.13.2 57809 1.1.1.1 53 UDP DNS malware.bakewithdavid.com "asyncrat (malware)" (static)
Maltrailはインジケータベースのネットワーク監視向けに設計されています。そのヒューリスティック検出は
トレイルマッチングを補完するものですが、エンドポイントテレメトリや汎用の侵入
防止システムの代替ではありません。
## 機能
- 3,000以上のバンドルされた静的ファイル、42の公開フィード統合、
およびオプションの運用者提供トレイルを組み合わせた完全なトレイルビルド。
- libpcapを使用したマルチスレッドRustセンサー。オプションでLinuxの`PACKET_FANOUT`キャプチャワーカーを利用可能。
- レポーティングインターフェース、イベント受信、HTTP APIを提供するPythonサーバー。
- レビューおよびバージョン管理が可能なプレーンテキストのカスタムトレイルとホワイトリスト。
- スキャン、DNS枯渇、DGA類似のルックアップ、疑わしいダウンロード、プロキシプローブ、
疑わしいUser-Agent値、および関連するネットワーク活動に対するヒューリスティック。
- ローカルイベントログ、リモートMaltrailログ、syslog経由のCEF、およびLogstash JSON出力。
- `maltrail-sensor -T`によるデプロイ検証と、オプションのPrometheusメトリクス。
## 目次
- [アーキテクチャ](#architecture)
- [レポーティングインターフェース](#reporting-interface)
- [パフォーマンス](#performance)
- [インストール](#installation)
- [インストーラー](#installer)
- [ソースからのビルド](#building-from-source)
- [Systemd](#systemd)
- [Docker](#docker)
- [設定](#configuration)
- [トレイル](#trails)
- [イベントとAPI](#events-and-api)
- [運用](#operations)
- [監視](#monitoring)
- [イベント保持](#event-retention)
- [ドキュメント](#documentation)
- [コントリビューション](#contributing)
- [プロジェクト](#project)
- [ライセンス](#license)
- [メンテナー](#maintainers)
- [スポンサー](#sponsors)
- [プレゼンテーションと出版物](#presentations-and-publications)
- [派生ブラックリスト](#derived-blacklist)
- [サードパーティ統合](#third-party-integrations)
- [謝辞](#acknowledgements)
## アーキテクチャ
Maltrailは、同じホストまたは別々のホストで実行できる2つの独立したプロセスで構成されています:```text
┌──────────┐ events (UDP or file) ┌──────────┐
│ sensor │ ───────────────────────► │ server │ ◄── browser
└──────────┘ └──────────┘
Rust Python
libpcap + PACKET_FANOUT reporting UI + API
trail matching + heuristics
センサーはトラフィックをキャプチャし、トレイルマッチングとヒューリスティック分析を実行してイベントを生成します。
イベントをローカルに書き込み（LOG_DIR）、リモートのMaltrailサーバーに送信し（LOG_SERVER）、あるいは
その両方を行うことができます。また、syslog経由でCEFを送信し（SYSLOG_SERVER）、LogstashにJSONを送信することも
できます（LOGSTASH_SERVER）。
サーバーはリモートイベントを受信・保存し、ローカルで利用可能なイベントログを提供し、 WebインターフェースとAPIを提供します。
レポーティングインターフェース
Maltrailには、検出されたトラフィックを探索するためのブラウザベースのレポーティングインターフェースが含まれており、 ライブ更新、フィールド対応検索、レトロハント、地理的ビュー、トリアージ、保存ビュー、エクスポートを備えています。
インターフェースはserver.pyによってHTTP_ADDRESS:HTTP_PORTで提供されます。プレーンなJavaScriptで、
サードパーティのランタイム依存関係は1つだけ（CSV解析用のPapaParse）で、ビルドステップはありません。一度に
1日分が表示され、利用可能な日次ログ上のイベント密度グリッドを兼ねる日付ピッカーで選択します。イベントは
/eventsからストリーミングされ、ブラウザ内で脅威（個別の(source, trail)ごとに1行）に集約され、
ソート可能なグリッドと詳細パネルに表示されます。
| 機能 | 備考 |
|---|---|
| ライブモード | 追加されたイベントはServer-Sent Events（/live）経由でプッシュされ、現在のビューにマージされます。SSEが利用できない場合、またはストリームが提供できないセッションでは、日次ログのバイト範囲のポーリングにフォールバックします。新たな高重大度の脅威はデスクトップ通知と音声アラートを発生させることができ、どちらもミュート可能です |
| 検索 | フィールドスコープ付きトークン（src: dst: port: proto: type: trail: info: family: tag: uid: sev: dir: status:。family:interlockはinterlock-1/-2を引き込みます。これは1回のフィードダンプが分割されて到着するシャードです）を、スペースでAND、-で除外、*ワイルドカード、CIDR（src:10.0.0.0/8）、数値範囲と比較（port:>1024、count:>=100）と組み合わせます。アクティブなフィルターは削除可能なチップとして表示されます |
| レトロハント | 表示中の日だけでなく、保持されているすべての日次ログから1つのインジケーターを検索します（/hunt）。日数制限、ウォールクロック予算、サンプル上限によって制限され、予算によって打ち切られた日は、完了した日とは別に報告され、完了した合計としてカウントされません。日ごとのサイドカーインデックス（LOG_DIR/index/、USE_EVENT_INDEX）により、スイープは一致しないすべての行をスキップでき、/countsが正確になります |
| ワールドマップ | 選択した日の国別イベント密度（/geo）で、各イベントの外部エンドポイントを配置します。外部アドレスに帰属できないイベントは、推測されるのではなく未マッピングとして報告されます。HOME_LAT / HOME_LONを設定すると、発信元の弧を描画します |
| トリアージ | 脅威ごとのステータス（新規 / 調査中 / 解決済み / 誤検知）、フリーテキストのメモ、タグ、非表示。ホワイトリストルールとOSINTピボットは行のコンテキストメニューから利用できます |
| 保存ビュー | 名前付きフィルタープリセット |
| エクスポート | 現在のフィルター済みビューをCSV、JSON、または無害化されたインジケーターとして出力 |
| 外観 | ダークテーマとライトテーマ、および個別のテキストサイズステップ |
トリアージ状態、保存ビュー、タグ、外観設定はブラウザ（localStorage）に保存され、サーバーには保存されません。これらはブラウザごと、オリジンごとに独立しており、アナリスト間で共有されません。
ネットワークフィルターで制限されたセッションは、自身のネットワークからのイベントのみを表示し、その制限はイベントリストだけでなく、カウント、マップ、ブラックリストのエンドポイントにも適用されます。
個々のアドレスの国とASNのエンリッチメントは、サーバーによってstat.ripe.netで検索され、サーバーは結果をキャッシュし、自身の/ripeエンドポイントからインターフェースに提供します。ブラウザはMaltrail以外とは通信しません。DISABLE_RIPE_LOOKUPSを設定すると、外向きの検索を完全にオフにできます。これらがない場合、またはインターネットアクセスのないホストでは、フラグは代わりにローカルのRIRテーブルから取得され、インターフェースの他のすべてはオフラインで動作します。
パフォーマンス
パフォーマンスは、プロセッサ、トラフィック構成、トレイルセットのサイズ、キャプチャドライバー、ネットワークインターフェースに依存します。以下の数値は、センサーのパケット処理パスを単独で測定したものであり、エンドツーエンドのライブキャプチャ測定ではありません。
ヒューリスティックを有効にし、150万行のトレイルセットを使用したAMD Ryzen 7 PRO 4750Uでの代表的な測定値：
| トラフィック | パケットあたりの時間 |
|---|---|
| ICMP echo、58バイト | 101 ns |
| TCP SYN、70バイト | 302 ns |
| バルクTLS、1,473バイト | 402 ns |
| ウォームキャッシュでのDNSクエリ、93バイト | 452 ns |
| 混合トラフィック、平均866バイト | 552 ns |
| HTTPリクエスト、169バイト | 602 ns |
| ユニークな名前でのDNSクエリ、93バイト | 1,102 ns |
同じ生成キャプチャ、構成、トレイルセットを使用したオフライン比較実行では、テストされたシステム全体で、廃止されたPythonセンサーよりも定常状態のパケットあたりコストが14～37倍低いと測定されました。これらの数値は、短いリプレイではトレイルの読み込みが支配的であるため、プロセス全体の時間と定常状態を分離しています。検出そのものは、sensor/tests/replay.rsの42ケースのコーパスによって別途検証されています。
対象システムで以下を使用して測定します：```bash cargo bench --manifest-path sensor/Cargo.toml --bench hotpath
1つのキャプチャワーカーがデフォルトで使用されます。追加のワーカーはキャプチャ容量を増やすことができますが、Linuxのフローハッシュはソースごとの状態をワーカー間で分割するため、一部のスキャンヒューリスティックの感度が低下します。文書化されたテストでは、シングルワーカーのヒューリスティックアラートの91%が2ワーカーで維持され、4ワーカーで86%、8ワーカーで65%でした。完全一致トレイルマッチングは変更されませんでした。`CAPTURE_FANOUT`は、キャプチャドロップメトリクスが必要性を示した場合にのみ増やしてください。
ベンチマーク手法、ハードウェア結果、プロファイラ出力、メモリ測定、およびライブファンアウトチェックは、[`sensor/docs/REPORT.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/REPORT.md)に文書化されています。
## インストール
### インストーラー
インストーラーは12のLinuxディストリビューション — Debian、Ubuntu、Fedora、Rocky、AlmaLinux、Arch、openSUSE LeapおよびTumbleweed、Alpine — に加えてFreeBSDとmacOSで、すべてのリリースにおいて検証されており、完全な結果は[`docs/compat`](https://github.com/stamparm/maltrail/blob/master/docs/compat)に記録されています。Raspberry Pi OSおよびその他の64ビットARMシステムは`aarch64`ビルドを使用します。32ビットARMにはビルド済みセンサーがなく、ソースからビルドする必要があります。```bash
curl -fsSL https://raw.githubusercontent.com/stamparm/maltrail/master/install.sh | sudo sh
依存関係をインストールし、/opt/maltrail 配下に管理対象のチェックアウトを作成し、ビルド済みセンサーのチェックサムを検証し、非特権の maltrail アカウントを作成し、systemd ユニットをインストールし、ログディレクトリと状態ディレクトリを準備し、センサーとサーバーを起動します。インストーラーを再実行すると、管理対象のチェックアウトがアップグレードされます。
昇格した権限で実行する前にスクリプトを確認してください。既存のチェックアウトから、ドライランではシステムを変更せずにコマンドを表示します:```bash sh install.sh --dry-run
共通インストーラーオプション:```bash
sh install.sh --role sensor # Install only the sensor
sh install.sh --ref 3.1.2 # Install a release tag instead of master
sh install.sh --no-service # Install without changing systemd
sh install.sh --dry-run # Print commands without applying them
sh install.sh --uninstall # Remove the managed installation; keep logs and state
ダッシュボードはインストール後、http://127.0.0.1:8338 で利用できます。同梱の
HTTP_ADDRESS は 0.0.0.0 であるため、ループバックだけでなく すべての インターフェースで到達可能であり、
デフォルトの認証情報は admin / changeme! です。ホストが信頼できないネットワーク上に置かれる前に、
USERS を変更し、HTTP_ADDRESS を 127.0.0.1 に設定する（またはサーバーを TLS 付きのリバースプロキシの背後に置く）ようにしてください。
初回の trail ビルドには数分かかることがあります。センサーは有効な trail セットが利用可能になるまで trail の一致を検出しません。systemd ユニットは起動前にセンサーの -T 検証を実行するため、権限の不足、書き込み不可能なログディレクトリ、または無効な trail セットがあると、起動が目に見える形で失敗します。