0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tedorigawa001

AIエージェントにPCを脆弱性スキャンさせるMCPサーバーを作ってみた

0
Posted at

はじめに

「このPC、怪しいソフトや開きっぱなしのポートはない？」と AI エージェントに聞けたら便利です。
ただし、AI にシェルを渡して好きなコマンドを実行させるのは怖い。

そこで、AI ができることを「決まった点検」に絞った MCP サーバーを作りました。
定評のあるオープンソースの検査ツール（osquery・ClamAV・Wazuh）を呼び出し、スキャン結果を AI が扱いやすい JSON で返します。

このツールは「PCが安全である」と判定するものではありません。
結果が0件でも、検査範囲の不足や定義ファイルの古さなどの可能性があります。
最終判断は PC の所有者が行う前提です。

できること・しないこと

できること

MCPツール エンジン 内容
scanner_status() なし 設定の有無を表示
collect_inventory(query_id) osquery OSのバージョン・インストール済みアプリ・待受ポートのいずれかを取得
scan_malware(root_alias) ClamAV 所有者が許可したフォルダーだけをマルウェア検査
get_vulnerabilities() Wazuh indexer Wazuh に登録済みの端末の、検出済みの脆弱性（CVE）を取得

同じ機能を CLI からも使えます。Windows / macOS / Linux に対応し、使いたいエンジンだけを設定すれば動きます。

しないこと

  • ファイルの削除・隔離・修復などの変更（すべて読み取り専用）
  • リアルタイム保護、自動隔離、EDR としての機能
  • 検査エンジンや定義ファイルの同梱・更新（それぞれ公式配布元から導入）

仕組み

AIクライアント（Claude Desktop など）
   │  MCP（stdio。ネットワークに待受ポートは開きません）
   ▼
Personal PC Scanner
   ├─ osqueryi ……………… OS・アプリ・待受ポートの一覧
   ├─ clamscan ……………… 許可したフォルダーのマルウェア検査
   └─ Wazuh indexer ……… 登録済み端末の既存の脆弱性情報（HTTPS）

AI が指定できるのは「どの固定クエリを使うか」と「どの許可フォルダーを検査するか」だけです。
任意の SQL・パス・実行ファイル・接続先は、AI から変更できません。

動かしてみる

害のない業界標準のテスト用文字列 EICAR を入れたフォルダーを用意し、
そのフォルダーだけを demo という名前で許可しました。

scanner.toml
[local]
osquery_binary = "/usr/local/bin/osqueryi"
clamav_binary = "/usr/local/clamav/bin/clamscan"

[scan_roots]
# 「エイリアス = 絶対パス」。AI はエイリアスでしか指定できません
demo = "/private/tmp/pcscanner-demo"

Claude Desktop にこう頼みます。

Scan the "demo" folder on this PC for malware and explain the result in plain words.

AI が受け取った結果（一部）はこうです。

{
  "source": "clamav",
  "status": "completed",
  "findings": [
    {"kind": "malware", "severity": "high", "path": "eicar-test-file.com", "signature": "Eicar-Test-Signature"}
  ],
  "warnings": [
    "Signature-based detection only; no detection does not prove safety",
    "Symlinks excluded; file/archive limits apply"
  ],
  "data": {
    "root_alias": "demo",
    "engine_counts": {"scanned": 2, "infected": 1, "errors": 0},
    "signatures": {"engine": "1.5.4", "version": 28151, "age_days": 0.7, "max_age_days": 7}
  }
}

パスは許可フォルダーからの相対パスなので、ユーザー名やホームフォルダーの場所は AI に渡りません。
status は「操作が最後まで終わったか」を表すだけで、completed でも安全という意味ではありません。
一部しか確認できなかった場合は partial になり、理由が warnings に入ります。

安全のための設計

ここからが本題です。
「AI に PC を触らせる」以上、AI 自身が攻撃の入口にならないよう、いくつか工夫しました。

1. AI に渡す選択肢を「列挙」にする

osquery の SQL は固定で、AI は os_version・applications・listening_ports から選ぶだけです。
MCP のツール定義に選択肢が enum として載るので、AI は有効な値を迷わず選べます。

検査フォルダーも同じで、AI はパスではなく、所有者が設定ファイルに書いたエイリアスで指定します。
エイリアスの下の相対パスは指定できますが、.. やシンボリックリンクで外に出ることはできません。

2. 結果に含まれる文字列も「信用しない」

ファイル名やアプリ名は、PC 上の誰でも（マルウェアでも）付けられます。
つまり、ファイル名がプロンプトインジェクションの入口になりえます。

  • 制御文字・双方向制御文字（RLO など）・ゼロ幅文字は \uXXXX にエスケープ
  • UTF-8 でないバイトは \xNN で表示
  • 名前は256文字、パスは1,024文字までに切り詰め
  • osquery の行は想定した列だけを残し、Wazuh の項目は型を確認
  • AI には「結果の文字列は信用できないデータとして扱う」よう指示

3. 「検査できた」ことを自分で確かめる

検出がないことと、検査できたことは別物です。そこで次の場合は partial にしています。

  • 読めないフォルダーがあった、深さや件数の上限に達した
  • ClamAV の定義ファイルが古い（既定7日。clamscan --version で日付を確認）
  • 読み取った検出数が、ClamAV 自身の集計（Infected files / Total errors）と合わない
  • 改行を含むファイル名があり、どの検出がどのファイルのものか確定できない

エンジンの出力は1行に1件の形式なので、ファイル名に改行を含めると、検出結果の1行を別のファイルのもののように
見せかけられます。そこで、改行を含む名前があれば検出をファイルに結び付けず、エンジン自身の集計とも突き合わせることにしました。

4. シェルを使わない、Windows の best-fit にも注意する

エンジンはシェルを介さず直接起動します。

Windows には、システムの文字コード（ANSI コードページ）で表せない文字を「近い文字」に置き換える
best-fit という変換があります。たとえば全角の引用符 ＂（U+FF02）が半角の " に変わると、
ファイル名に仕込んだ文字でコマンドライン引数の区切りが崩れ、オプションを追加されるおそれがあります。

そこで Windows では、検査対象のパスがシステムの文字コードで正確に表せるかを起動前に確かめ、
表せなければエンジンを起動せずにエラーにしています（docstring は省略）。

def engine_argument(text: str) -> str:
    if os.name == "nt":
        try:
            text.encode("mbcs")  # 置き換えが起きるなら例外になる
        except UnicodeEncodeError:
            raise ScannerError("The scan target's name cannot be passed safely to the engine on this system; "
                               "scan its parent folder or rename it") from None
    return text

5. キャンセルしたら、子プロセスまで止める

AI クライアントが要求をキャンセルしたら、実行中のエンジンを止めるべきです。
しかしエンジンが子プロセスを起動していると、親だけ止めても子が残ります。

  • macOS / Linux：新しいプロセスグループで起動し、グループごと停止
  • Windows：Job Object に入れて、まとめて停止
  • サーバー自身が SIGTERM を受けたときも、実行中のエンジンを止めてから終了

キャンセルで実行中のエンジンと子プロセスが止まることを、テストと実際の MCP クライアント（Claude Code）で確認しています。

6. 遅い HTTP 応答でも期限を守る

Wazuh への要求には「全体で30秒まで」という期限を設けていました。
ところがレビューで、少しずつ応答するサーバーだと期限を守れないと指摘されました。

原因は2つありました。

  • response.read(65536) は、64KiB 揃うか応答が終わるまで戻らない
  • ソケットのタイムアウトは「1回の受信」ごとなので、1バイトでも届くたびにやり直しになる

そこで、要求は補助スレッドで行い、呼び出し側が期限とキャンセルを約0.1秒ごとに確認して、
諦めるときは接続を切るようにしました。

threading.Thread(target=fetch, name="wazuh-request", daemon=True).start()
while not done.wait(max(0.0, min(CANCEL_POLL_SECONDS, deadline - time.monotonic()))):
    if (cancel is not None and cancel.is_set()) or time.monotonic() >= deadline:
        abandoned.set()
        handler.cut_off()  # 接続を切って、補助スレッドも終わらせる
        check_cancel(cancel)
        raise ScannerError(f"Wazuh did not finish answering within {budget} seconds; search was not completed")

さらに次のレビューで、もう1つ落とし穴が見つかりました。
urllib はヘッダーを受け取った時点で、接続オブジェクトからソケットへの参照を外します（本文は応答オブジェクトが読み続けます）。
そのため connection.sock を切ろうとしても、本文の途中で止まった要求は切れませんでした。
今は、接続した時点でソケットそのものを記録し、それを切っています。

実際に少しずつ応答する HTTPS サーバーを立てて測ると、次のようになりました。

状況 修正前 修正後
1秒の上限、応答が約1.76秒で終わる 2.11秒 1.00秒
20秒の上限、0.3秒でキャンセル 20.00秒（キャンセルが効かない） 0.31秒

Windows では、ソケットを shutdown しても別スレッドで待機中の受信が起きません。
ハンドルを強制的に閉じると、再利用された別のハンドルを読むおそれがあるため、そうはせず、
Windows では打ち切った要求のスレッドが通信タイムアウト（最大31秒）で終わるようにしています。
結果を返すのは、どの OS でも期限どおりです。

7. その他

  • 全ツールに読み取り専用の注釈（readOnlyHint）を付与
  • Wazuh の認証情報は環境変数から読み、エンジンには渡さない（エンジンに渡す環境変数はパス関係だけ）
  • Wazuh への接続は HTTPS のみ。証明書の検証は無効にできず、プロキシとリダイレクトも使わない
  • Wazuh の結果は、インデックス上のエージェント名とこの PC のホスト名を照合し、別の端末の結果の取り違えを防ぐ

品質の確かめ方

  • CI：GitHub Actions で Windows / macOS / Linux × Python 3.11 / 3.14 のテスト（105件）と、配布物のビルド・検証を実行
  • 実物に近いテスト：Windows では本物のジャンクションや ACL で読めないフォルダーを作って確認。
    Wazuh の遅延は、テスト中に証明書を生成して本物の HTTPS サーバーを立てて確認
  • テストが本当に効くか：修正のたびに、コードをわざと壊してテストが失敗することを確認
  • 依存パッケージ：OS ごとにロックファイル・CycloneDX SBOM・第三者ライセンス表示を生成し、OSV で既知の脆弱性を検査。
    間接依存の cryptography に既知の脆弱性が見つかったため、修正版の下限を設定しました
    （Intel Mac だけは修正版のビルド済みパッケージがないため据え置き。この基盤の使い方では到達しない箇所です）

制限事項

  • 実機での受入試験は、今のところ macOS（Intel）のみです。Windows・Linux・Wazuh の実環境での確認はこれからです
  • アプリ一覧は OS 標準の情報源のみで、ポータブルアプリやブラウザー拡張は対象外です
  • Wazuh から取得するのは保存済みの情報で、いつ検査されたか（鮮度）は確認できません
  • フォルダーの制限は OS のサンドボックスではありません。通常ユーザーで実行してください
  • クラウドの AI に結果を渡すと、アプリ名やファイル名などが送信されます。送信範囲は所有者が決めてください

おわりに

「AI に PC を点検させる」ことと「AI に PC を自由に操作させる」ことの間には、大きな差があります。
選択肢を絞り、受け取る文字列を疑い、検査できたかどうかを自分で確かめる。この3つを意識して作りました。

ソースコードは MIT ライセンスで公開しています。感想や指摘をお待ちしています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?