maltrail v3.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 セットがあると、起動が目に見える形で失敗します。
インストーラーのテストハーネスは 12 のディストリビューションをカバーしており、「インストールされた」ことは検証内容ではありません。それぞれでサーバーが起動され /ping が要求され、センサーは -T で自己検証を求められ、ユニットは解決可能なパスがチェックされ、インストーラーが再実行されてアップグレードが運用者の設定を保持することが証明され、--uninstall が実行されます。すべての結果はプラットフォームごとに docs/compat に記録され、そこにあるページは手書きではなくそれらの行から生成されています。
Alpine やその他の musl システムには -musl センサービルドが提供されます。以前は、ビルド済みバイナリが glibc リンクであり自分でコンパイルする必要があると伝えられていましたが、センサーは musl 上でネイティブにビルドおよび実行されるため、それはプラットフォームの制限ではなく、欠落していた成果物でした。
ソースからのビルド
センサーには Rust 1.74 以降、libpcap 開発ヘッダー、およびシステムの capability ツールが必要です。サーバーと trail アップデーターには Python 3.6 以降が必要です。
ディストリビューションのパッケージをインストールします:```bash
Debian / Ubuntu / Raspberry Pi OS
sudo apt-get install cargo libpcap-dev libcap2-bin python3
RHEL / Fedora
sudo dnf install cargo libpcap-devel libcap python3
openSUSE / SLES
sudo zypper install cargo rust libpcap-devel libcap-progs python311
次に、センサーをビルドして検証します:```bash
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
cargo build --release --manifest-path sensor/Cargo.toml
sudo setcap cap_net_raw,cap_net_admin=eip \
sensor/target/release/maltrail-sensor
sudo install -d -o "$USER" -g "$(id -gn)" -m 750 /var/log/maltrail
sensor/target/release/maltrail-sensor -T
sensor/target/release/maltrail-sensor
別のターミナルまたは別のホストでサーバーを起動します:```bash python3 server.py
ビルド済みセンサーバイナリは、SHA-256チェックサム付きで最新リリースに添付されています。Linux `x86_64` および `aarch64` は glibc と musl の両方に対応し、macOS は Apple シリコンと Intel、FreeBSD `amd64`、そして Windows `x86_64` です。
glibc ビルドは libpcap を静的にリンクし、glibc 2.28 をターゲットとしているため、必要なのは C ライブラリだけです — RHEL 8+、Debian 10+、Ubuntu 18.04+、Leap 15.x のいずれでもインストールするものはありません。musl ビルドは完全に静的であるため、Alpine では何も必要ありません。Windows ビルドは 64 ビットで、Windows 10 以降と、起動前にインストールされた [Npcap](https://npcap.com) が必要です — `wpcap.dll` はロード時の依存関係であるため、これがないとローダーはキャプチャ時に失敗するのではなく実行ファイルを拒否します。アーカイブにもそのように記載されています。
**3.1.1 以前**のバイナリはそうではありませんでした。それらは libpcap を動的にリンクし、AlmaLinux ビルドホストが使用する名前で要求していました。Debian と Ubuntu は同じライブラリを古い名前 `libpcap.so.0.8` で提供しているため、これらのバイナリは起動する前に停止します —```
./maltrail-sensor: error while loading shared libraries: libpcap.so.1: cannot open shared object file
— libpcap がインストールされているマシン上で。install.sh が不足している名前をリンクします。手動で行う場合:```bash
adjust the directory for your architecture: aarch64-linux-gnu, or /usr/lib64 on RPM distributions
sudo ln -sf /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 /usr/lib/x86_64-linux-gnu/libpcap.so.1 sudo ldconfig
### Systemd
付属の `packaging/systemd/` ユニットは、両方のプロセスを非特権ユーザー `maltrail` として実行します。Systemd は `/var/log/maltrail` と `/var/lib/maltrail` を作成し、ファイルシステムアクセスを制限し、センサーに `CAP_NET_RAW` と `CAP_NET_ADMIN` を付与します。
インストーラーはこれらのユニットを自動的に設定します。既存のソースインストールの場合は、[`sensor/docs/INSTALL.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/INSTALL.md) の手動サービス手順に従ってください。
サービスの状態とログは次のコマンドで確認します:```bash
systemctl status maltrail-sensor maltrail-server
journalctl -u maltrail-sensor -f
Docker
付属のComposeデプロイメントを次のコマンドで起動します:```bash docker compose -f docker/docker-compose.yml up -d
コンテナの設定、ストレージ、権限、ヘルスチェックについては
[`docker/README.md`](https://github.com/stamparm/maltrail/blob/master/docker/README.md) に記載されています。
## 設定
Maltrail は `maltrail.conf` を読み込みます。このファイルには `[Sensor]` と `[Server]` の設定が別々に含まれています。インストーラーは管理対象の設定を `/etc/maltrail.conf` に配置します。
よく使用されるセンサーオプションには次のものがあります:
| オプション | 目的 |
| --- | --- |
| `MONITOR_INTERFACE` | キャプチャインターフェース。`any` を指定するとサポートされているすべてのインターフェースを選択します |
| `CAPTURE_FILTER` | BPF キャプチャフィルター |
| `CAPTURE_FANOUT` | Linux キャプチャソケットの数。デフォルトは 1 |
| `CAPTURE_WORKERS` | キャプチャワーカー。それぞれ 1 ソケット。デフォルトは `CAPTURE_FANOUT` のため、どちらも設定されていない場合は 1 |
| `LOG_DIR` | ローカルイベントログディレクトリ |
| `TRAILS_FILE` | 生成されたトレイルデータベース |
| `LOG_SERVER` | リモート Maltrail イベントサーバー |
| `SYSLOG_SERVER` | CEF syslog の送信先 |
| `LOGSTASH_SERVER` | Logstash JSON の送信先 |
| `STATS_ADDRESS` | Prometheus メトリクスのリスナー。設定しない限り無効 |
| `UPDATE_PERIOD` | トレイルの更新間隔 |
| `STATIC_TRAILS_URL` | 組み立てられた静的トレイルセットの取得元。日付付きリリースに固定することで、新しいコンテンツがいつ反映されるかを制御できます |
| `USER_WHITELIST` | アラートを発生させたくない、運用者が管理するインジケーター |
| `CUSTOM_TRAILS_DIR` | 運用者が管理するトレイルディレクトリ |
| `STATIC_TRAILS_DIR` | trails リポジトリの任意のチェックアウト。UI でトレイルの出典引用を表示するためにのみ使用されます |
`PROCESS_COUNT` は廃止された Python センサーとレガシーなイベントログスロットルに適用され、
Rust センサーのワーカー数を設定するものでは**ありません**。キャプチャワーカーは代わりに
`CAPTURE_FANOUT` または `CAPTURE_WORKERS` で設定してください。
設定を変更した後は、デプロイメントチェックを実行してください:```bash
sensor/target/release/maltrail-sensor -T
チェックは、設定、trail、ホワイトリストエントリ、キャプチャフィルタ、権限、ログ ストレージ、更新サポート、ワーカー設定を検証します。成功したチェックには、ファイルが存在することの確認だけでなく、正の trail 数と ホワイトリスト数が含まれます。
Trails
trail とは1つの指標 — ドメイン、URL、IPアドレス、IP:port ペア、User-Agent、JA3/JA4
フィンガープリント、または証明書ハッシュ — と、それが何を意味するか、どこから来たかをまとめたものです。アップデータは
4つのソースを TRAILS_FILE に、この順序でマージします:
| source | where it comes from |
|---|---|
| Feeds | feeds/*.py、各パブリッシャーからあなたのデプロイメントが直接取得 |
| Custom | CUSTOM_TRAILS_DIR と CUSTOM_TRAILS_URL、あなた自身の指標 |
| Static | stamparm/trails から組み立てられたセットで、STATIC_TRAILS_URL から取得。別ライセンス |
| Engine lists | data/mass_scanner*.txt、ほとんど変更されないためここに同梱 |
静的 trail は独自のリポジトリに存在します。検出コンテンツは1日に何十回も変更されますが、
エンジンはそうではなく、それらを一緒に保つことは、検出の更新にコードのプルが必要となり、
このリポジトリの履歴が使用不能になることを意味していました。STATIC_TRAILS_URL は最新の公開
セットを指します:```text
STATIC_TRAILS_URL https://github.com/stamparm/trails/releases/latest/download/trails.csv.gz
特定の `content-YYYYMMDD-HHMM` リリースを指定してバージョンを固定することもできます。そうすれば、不良な公開が即座にグローバルに広がることはありません。このセットは `TRAILS_FILE` の隣にキャッシュされ、これがオフラインまたはエアギャップ環境での再ビルドを可能にします。公開された `sha256` はダウンロード前にチェックされるため、コンテンツの変更よりも頻繁に更新するデプロイでは 11 MB ではなく 65 バイトを転送し、ダイジェストと一致しないペイロードはキャッシュを優先して拒否されます。
`update_trails()` は、ビルドが成功した後にのみ、新しい `TRAILS_FILE` をアトミックに公開します。何も返さないフィードは名前で報告されるため、デプロイが静かに廃止されたソースに気付かず依存することはありません。
独自のインジケーターは `CUSTOM_TRAILS_DIR` の下に、絶対にイベントを発生させてはならないものは `USER_WHITELIST` に追加してください。アップグレードで上書きされないよう、両方ともインストールディレクトリの外に置いてください。
静的なトレイルの貢献は [stamparm/trails](https://github.com/stamparm/trails) へ、新しいフィードはこちらへ。いずれの場合も、インジケーターには分類と誰でも確認できるソースが必要です — [Contributing](#contributing) を参照してください。
## イベントと API
Maltrail は検出ごとに 1 つの空白区切りイベントを記録し、値にスペースが含まれる場合は CSV クォートを使用します:```text
"<time>" <sensor> <src_ip> <src_port> <dst_ip> <dst_port> <proto> <type> <trail> "<info>" <reference>
type フィールドは何がマッチしたかを識別し、DNS、IP、IPORT、URL、PATH、HTTP、
UA、PORT、CERT、JA3、JA4 を含みます。info フィールドにはトレイル分類が含まれ、
reference はそれを生成した静的リスト、フィード、カスタムソース、またはヒューリスティックを識別します。
JA3/JA4 タイプは TLS のクライアントフィンガープリントで発火します。インプラントの TLS スタックは
あらゆるアドレスとドメインのローテーションを生き延びるため、他のすべてが焼失した後もその hello ハッシュは
マッチし続けます（abuse.ch SSLBL JA3 フィードによって公開されています）。
インジケータ検索
/check を使用して、1 つのドメイン、IP アドレス、または URL を照会します:```bash
curl 'http://127.0.0.1:8338/check?q=www.sub.evil.example'
## 検出
### 検出ルール
- 検出ルールは `rules/` ディレクトリにあります。
- 各ルールは、検出ロジックを定義する YAML ファイルです。
- ルールは、疑わしいアクティビティのパターンを識別するために使用されます。
### 検出エンジン
- 検出エンジンは、ログとイベントを分析する役割を担います。
- エンジンは、ルールをログデータに適用してアラートを生成します。
### アラート
- アラートは、ルールが疑わしいアクティビティを検出したときに生成されます。
- アラートは、分析のために SIEM またはその他の監視ツールに送信できます。
## 設定
### 設定ファイル
- 設定ファイルは `config/` ディレクトリにあります。
- 設定ファイルは、検出エンジンの動作を定義します。
### 環境変数
- 環境変数は、検出エンジンの動作を設定するために使用できます。
- 環境変数は、設定ファイルの設定を上書きします。
## 使用方法
### インストール
- リポジトリをクローンします。
- 依存関係をインストールします。
### 実行
- 検出エンジンを実行するには、次のコマンドを使用します。
```bash
python3 main.py
オプション
-cまたは--config: 設定ファイルへのパスを指定します。-rまたは--rules: ルールディレクトリへのパスを指定します。-lまたは--log: ログファイルへのパスを指定します。
貢献
- 貢献を歓迎します。
- プルリクエストを送信する前に、貢献ガイドラインをお読みください。
ライセンス
- このプロジェクトは MIT ライセンスの下でライセンスされています。```json { "query": "www.sub.evil.example", "found": true, "trail": "evil.example", "info": "asyncrat (malware)", "reference": "(static)", "confidence": 100 }
`confidence` フィールド（0〜100、利用できない場合は `null`）は、ソースがそのリスト項目をどれだけ強く裏付けているかを示します。単一のフィードなら 40、独立して一致するフィードが追加されるごとに +15 を加算して最大 100 となり、運用者自身のカスタムエントリと静的エントリには満点が与えられます。これは trail 更新時にフィードの一致状況から計算され、`trails.csv` の隣にある `trails.confidence` サイドカーに書き込まれます。`UPDATE_SERVER` から trail を取得するサーバーにはスコアリングのための来歴がないため、`null` を報告します。トリアージの優先順位付けに活用してください。単一フィードのリスト項目が 40 であるなら、ファイアウォールルールに採用する前に再確認する価値があります。
サブドメインのルックアップは、リストされている親ドメインに一致することがあります。URL ルックアップは、ホスト単体をチェックする前に `host/path` をチェックします。サーバーはメモリマップされた trail データベースを読み取り、再起動なしで trail の更新を監視します。
公開の静的 trail とフィード trail は、リモートセンサーが使用する `/trails` エンドポイントと同様に、認証なしで利用できます。カスタム trail には認証済みセッションが必要で、認証されていないカスタム専用のルックアップはミスとして報告されます。イベントデータは引き続き認証が必要です。
## 運用
### 監視
`maltrail-sensor -T` をデプロイと設定のゲートとして使用してください。付属の systemd ユニットはこれを `ExecStartPre` として実行します。
検出そのものが機能していること（プロセスが起動するだけでなく）を確認するには、次を実行してください:```bash
python3 server.py --detect-test
これは、エミュレートされた悪意のあるトラフィックの細工された pcap（DNS クエリ、IP、IP:port、URL パス、Host ヘッダーに対するトレイルヒット、および SQL インジェクション、トラバーサル、RCE、XSS、プロキシプローブ、シンクホール、Host 欠落、ポート/Web/感染スキャンのヒューリスティックを含む）を、インストール済みのセンサーを通して再生し、期待されるすべての検知が発火することを検証します。root も、インターフェースも、独自のトレイルセットも必要ありません。正常なインストールでは 20/20 detection(s) fired と出力されます。
STATS_ADDRESS が設定されている場合、少なくとも以下の Prometheus メトリクスを監視してください：
| メトリクス | 運用上の意味 |
|---|---|
maltrail_up == 0 | キャプチャワーカーが動作していない |
maltrail_capture_dropped_total の増加 | キャプチャリングがパケットをドロップしている |
maltrail_local_log_errors_total の増加 | イベントは生成されたがローカルに書き込めなかった |
maltrail_remote_log_errors_total の増加 | イベントをリモートシンクに配信できなかった；DISABLE_LOCAL_LOG_STORAGE の場合、それらは失われる |
maltrail_trail_generation が進まない | アクティブなトレイルセットが更新されていない |
maltrail_log_dir_free_bytes | ローカルイベントストレージの残り容量 |
maltrail_state_saturations_total の増加 | ヒューリスティックの状態上限に達した |
maltrail_throttle_evictions_total の増加 | イベントスロットルテーブルが上限に達し、設定より早くイベントが集約されている |
状態の飽和は対応するヒューリスティックに影響しますが、正確なトレイルマッチングは引き続き有効です。
SIGHUP を送信するか、systemctl reload maltrail-sensor を使用してトレイルのリロードを要求します。別のプロセスによって更新されたトレイルファイルは自動的に検出され、センサーを再起動することなくワーカーに公開されます。
圧縮された観測可能ストア（USE_CONDENSED_STORAGE、meta.sqlite）は、サーバーのノベルティビューとレトロハントビューをサポートします。日次イベントログのサイドカーインデックス（USE_EVENT_INDEX、LOG_DIR/index/*.sqlite、ディスク上でログサイズの約2倍）は、/counts を正確にし、/hunt を高速にするものです；これはログ自体からインクリメンタルに維持され、server.py --rebuild-index で再構築できます。廃止されたセンサーとの互換性は sensor/docs/COMPATIBILITY.md に記載されています。
イベント保持
Maltrail はイベントログをローテーションまたは削除しません。保持、アーカイブ、削除は、ストレージ要件と組織のポリシーに従って運用者が定義する責任があります。
推奨される実践：
LOG_SERVER、SYSLOG_SERVER、またはLOGSTASH_SERVERを使用して、耐久性のあるイベントコピーをリモートの Maltrail サーバーまたは SIEM に送信します。- 予想されるイベントレートに対して十分な余裕を持って
maltrail_log_dir_free_bytesにアラートを設定します。 - 外部ツールを使用して、ローカルの日次ログをローテーション、アーカイブ、または削除します。
- レポートインターフェースが必要とするファイルは
LOG_DIRに非圧縮で保持し、圧縮ファイルは別の場所にアーカイブします。
ログファイルシステムが満杯になると、センサーはイベントを追記できません。イベントログには、一部の法域で個人データとして規制される IP アドレスやドメインが含まれる場合があります；保持ポリシーは該当する要件を考慮する必要があります。
合成トラフィック
実際のトラフィックを待たずに、検知とダッシュボードの両方がまだ機能することを確認するには：```bash python3 server.py --detect-test # assert every detection fires, then exit python3 server.py --detect-test --keep DIR --serve # ...and keep the events, serving them on :8338
`--keep` は `sensor/tests/corpus/` を同じログに再生し、ダッシュボードが異なる形で描画する図形のうち、どれにイベントが背後にあるかを出力します。これにより、欠落したアイコン、色、グリフが推測ではなく可視化されます。タイムスタンプは最新の日が今日になるようにシフトされます。センサーバイナリが必要です（`cargo build --release --manifest-path sensor/Cargo.toml`）。
公開デモのデータは、そのような実行から再生成されます：```bash
python3 sensor/tools/gen_demo_js.py --from DIR/logs # tops up html/js/demo.js
ドキュメント
| ドキュメント | 内容 |
|---|---|
sensor/docs/INSTALL.md | インストール、権限、設定、トラブルシューティング |
sensor/docs/ARCHITECTURE.md | センサーの内部構造とデータフロー |
sensor/docs/COMPATIBILITY.md | 廃止された Python センサーとの意図的な差異 |
sensor/docs/REPORT.md | 測定値、プロファイル、テスト結果 |
sensor/docs/ROADMAP.md | 未完了のセンサー作業 |
SekuriPy Labs | エンジニアリングノート、ベンチマーク、解説記事 |
コントリビューション
Trail の追加、フィードのメンテナンス、バグ報告、ドキュメント、センサーの改善を歓迎します。 Trail の投稿には信頼できる情報源を含め、可能な限り最も狭い適切な 分類を使用してください。
コードを提出する前に、関連するチェックを実行してください。センサーの完全なゲートは次のとおりです:```bash bash sensor/tools/check.sh
フォーマット、警告を拒否する Clippy、およびデバッグとリリースのテストスイートを実行します。Python サーバースイートを実行するには、次を実行します:```bash
bash tests/run.sh python3
WindowsビルドはLinuxから実行でき、そのバグはそこで発見されている:```bash sh sensor/tools/check_windows.sh
センサーを mingw-w64 でクロスコンパイルし、Npcap のユーザー空間ライブラリをそのインストーラー（NSIS アーカイブなので、何もインストールされない）から抽出し、その結果を Wine 上で実行する — ユニットスイート全体、出荷時の設定に対する `-T`、ネイティブバイナリとバイト単位で比較される pcap コーパス、そして Windows 版 Python 上で `/ping` に応答するサーバー。ライブキャプチャだけはカバーできない。それには Npcap のカーネルドライバーと実際の Windows マシンが必要である。前提条件は `gcc-mingw-w64-x86-64`、`wine`、`p7zip-full` である。
## プロジェクト
### ライセンス
**TL;DR:** Maltrail は MIT ライセンスだが、Maltrail Trails データセットには別個の条件がある。独立した IOC の検索/参照は問題ないが、商用製品やサービスにおいて Trails をインテリジェンスソースとして体系的に使用するには許可/ライセンスが必要である。
Maltrail は MIT License の下で配布されている。[`LICENSE`](https://github.com/stamparm/maltrail/blob/master/LICENSE) を参照。
それがエンジンである。静的トレイルセットは別個の条件の下での別個の成果物である。内部の防御用途、研究および教育には無料だが、商用製品、サービス、MSSP もしくは MDR の提供、または再配布されるフィードにはライセンスが必要である。MIT のエンジンであっても、コンテンツを自由に販売できるようになるわけではない — 課金するものに同梱する前に、[stamparm/trails](https://github.com/stamparm/trails) の [`LICENSE.md`](https://github.com/stamparm/trails/blob/main/LICENSE.md) を参照のこと。
### メンテナー
- Miroslav Stampar ([@stamparm](https://github.com/stamparm))
- Mikhail Kasimov ([@MikhailKasimov](https://github.com/MikhailKasimov))
### スポンサー
- [Sansec](https://sansec.io/) (2024–2025)
- [Sansec](https://sansec.io/) (2020–2021)
### プレゼンテーションと出版物
- 第47回 TF-CSIRT ミーティング、プラハ、2016年
([スライド](https://web.archive.org/web/20161109135211/https://www.terena.org/activities/tf-csirt/meeting47/M.Stampar-Maltrail.pdf))
- _Detect attacks on your network with Maltrail_、Linux Magazine、2022年
([記事](https://www.linux-magazine.com/Issues/2022/258/Maltrail))
- _Best Cyber Threat Intelligence Feeds_、Silent Push、2022年
([レビュー](https://www.silentpush.com/blog/best-cyber-threat-intelligence-feeds))
- _Research on Network Malicious Traffic Detection System Based on Maltrail_、Nanotechnology
Perceptions、2024年
([論文](https://nano-ntp.com/index.php/nano/article/view/1915/1497))
### サードパーティ統合
- [FreeBSD Port](https://www.freshports.org/security/maltrail)
- [OPNsense Gateway Plugin](https://github.com/opnsense/plugins/pull/1257)
- [D4 Project](https://www.d4-project.org/2019/09/25/maltrail-integration.html)
- [BlackArch Linux](https://github.com/BlackArch/blackarch/blob/master/packages/maltrail/PKGBUILD)
- [Validin](https://x.com/ValidinLLC/status/1719666086390517762)
- [Maltrail Add-on for Splunk](https://splunkbase.splunk.com/app/7211)
- [Maltrail decoder and rules for Wazuh](https://github.com/MikhailKasimov/maltrail-wazuh-decoder-and-rules)
- [GScan](https://github.com/grayddq/GScan) (トレイルのみ)
- [MalwareWorld](https://www.malwareworld.com/) (トレイルのみ)
- [oisd domain blocklist](https://oisd.nl/?p=inc) (トレイルのみ)
- [NextDNS](https://github.com/nextdns/metadata/blob/e0c9c7e908f5d10823b517ad230df214a7251b13/security/threat-intelligence-feeds.json) (トレイルのみ)
- [NoTracking](https://github.com/notracking/hosts-blocklists/blob/master/SOURCES.md) (トレイルのみ)
- [OWASP Mobile Audit](https://github.com/mpast/mobileAudit#environment-variables) (トレイルのみ)
- [Mobile Security Framework MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/12b07370674238fa4281fc7989b34decc2e08876) (トレイルのみ)
- [pfBlockerNG-devel](https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/www/pfblockerng/pfblockerng_feeds.json) (トレイルのみ)
- [Sansec eComscan](https://sansec.io/kb/about-ecomscan/ecomscan-license) (トレイルのみ)
- [Palo Alto Networks Cortex XSOAR](https://xsoar.pan.dev/docs/reference/integrations/github-maltrail-feed) (トレイルコネクター)
### 謝辞
- Thomas Kristner
- Eduardo Arcusa Les
- James Lay
- Ladislav Baco (@laciKE)
- John Kristoff (@jtkdpu)
- Michael Münz (@mimugmail)
- David Brush
- @Godwottery
- Chris Wild (@briskets)
- Keith Irwin (@ki9us)
- Simon Szustkowski (@simonszu)