AccessScope 操作マニュアル

サーバのアクセスログから、攻撃の試みを根拠のログ行つきで見つける診断ツールの使い方です。画面で診断する手順を先に説明して、コマンドでの使い方は 8 章にまとめています。

1. AccessScope について

AccessScope は、Web サーバや SSH サーバがすでに残しているログを読んで、攻撃の試みを探す診断ツールです。見つけたものには、根拠になったログの行を付けて示します。自分でサーバを運用していて、ログに怪しいアクセスが残っていないかを確かめたい方に向いています。

ログは読むだけです。ログの変更も削除もせず、通信を遮断することも、権限を上げることもありません。診断そのものは、LLM もネットワークも使いません。

Mac は RoamSwitch の DMG に、Linux は RoamSwitch の deb / rpm / tarball に入っています。RoamSwitch とは別の道具で、ライセンスは Apache License 2.0 です。起動するときは、Mac ではアプリのアイコンを、Linux ではアプリの一覧の「AccessScope」を選びます。

保存されるファイル

AccessScope が自動で保存するのは、設定、見つけたログの一覧、除外ルール、前回との比較の記録です。どれも ~/.config/accessscope/ の下に、自分だけが読み書きできる権限で置かれます。

アップデート

Mac は、設定の「アップデート」で「アップデートを確認」を押したときだけ lafine.net に接続します。この端末やログの情報は送らず、ダウンロードしたファイルは署名を確かめてからインストールします。Linux にはアプリ内のアップデートがなく、パッケージの更新で更新します。

2. はじめての診断

1. ログを選びます。いちばん手軽なのは「この端末のログを探す」です。nginx や Apache、SSH などのログを自動で探して、「この端末で見つかったログ」に並べます。場所が分かっているときは、「ファイルを選ぶ」か「フォルダを選ぶ」で選ぶか、ウィンドウの上にファイルやフォルダをドロップします。
2. 「期間」を選びます。初期値は「直近 7 日」で、「直近 24 時間」「直近 30 日」「すべて」にも変えられます。期間は今から数えるので、古いログを診断したいときは「すべて」にします。
3. 「診断する」を押します。「ログを読んでいます」「解析しています」と進み具合が出て、終わると結果が開きます。

3. 読めるログと、探す場所

ログの種類は、中身を見て自動で判別します。gzip で圧縮された回転済みのログも、そのまま読めます。フォルダを選ぶと、中にあるログらしいファイルをまとめて読みます。

「この端末のログを探す」は、標準の場所と、Web サーバの設定ファイルが指しているログの場所を調べます。並ぶのは、ログとして読めると確かめられたものだけです。

Docker のコンテナ

「Docker のコンテナも調べる」にチェックを入れると、この端末の Docker のログも対象にできます。診断の前に、実行するコマンドと対象のコンテナが確認画面に出て、「同意して診断」を押したときだけ読みます。読み取りだけで、権限は上げません。

LLM でログを探す(任意)

見つからないときは、「LLM でも探す」で、LLM に場所を探させることもできます。渡すのは、動いているサーバの名前や、/var/log などにあるファイルの名前といった環境の事実だけで、ファイルの中身は渡しません。提案は、読めることを確かめてから、チェックが外れた状態で出ます。設定は 7 章を見てください。

4. 結果の読み方

診断が終わると、4 つのタブで結果を確かめられます。

検知の見方

検知は「SQL インジェクションの試み」のように名前で表示されて、深刻度(高・中・低)と確度が付きます。確度は、ログだけでどこまで言えるかを表します。

• 確定は、ログだけで言えることです。
• 有力は、その試みがあった可能性が高いことです。
• 仮説は、ログだけでは確かめられないことです。

「根拠のログ行」を開くと、その検知の元になったログの行を、そのまま見られます。普段は閉じてあるので、まず名前と理由を読んで、気になったものだけ開いてください。

総合リスク(0 から 100)は、深刻度と確度で重みを付けた目安です。件数が多いだけでは膨らまず、深刻度が高の検知が 1 件もなければ「高」にはなりません。確率ではないので、目安として見てください。

5. 見る件数を減らす

除外ルール

自社の事務所の IP、死活監視、自社の脆弱性診断など、出ると分かっている検知は、報告から外せます。外した検知は捨てずに、理由つきで件数を残します。

1. 「検知」タブで、検知の IP の横にある「この IP を除外する…」を押します。
2. 理由を入れて「除外ルールに追加」を押します。理由は報告に残ります。
3. 確認のダイアログで内容を確かめて、承認します。次の診断から効きます。

設定の「除外ルール」には、いま有効なルールが一覧で出ます。表示だけで、ここでは編集できません。細かい条件のルールは、設定のフォルダに置くファイル(suppress.toml)に書きます。書き方は 8 章にあります。深刻度が「高」の検知は、除外しても外れず、報告に残ります。

前回との比較

同じログの組み合わせを続けて診断すると、前回の記録と比べて、新しく現れた検知に「新規」の印が付きます。「検知」タブの「新規のみ」にチェックを入れると、新規だけに絞れます。初回は、すべて新規として扱います。記録に入るのは検知の指紋(ハッシュ)、種別、深刻度、件数、時刻だけで、ログの文字列は入りません。

6. 結果の書き出し

結果画面の上にあるボタンで、結果を持ち出せます。

「エクスポート…」では、ブロックリストの形式として fail2ban-ip、nftables、ipset、nginx-deny、apache-require、csv を選べます。検知の一覧は CSV、SARIF、JSON で書き出せます。

ブロックリストは、「含める条件」を「既定」「厳しめ」「広め」から選べて、書き出す IP の数は保存の前に表示されます。公式のクローラの IP と除外ルールの対象の IP は、常に入りません。

7. LLM による分析(任意)

診断の結果を、LLM に文章にまとめさせる機能です。初期状態ではオフです。使うには、設定の「LLM 連携」で「LLM による分析を有効にする」にチェックを入れて、「使う LLM」を選び、「保存」を押します。選べるのは claude、opencode、codex、agy のうち、その端末にコマンドが入っているものです。

送る内容

• 生ログは送りません。送るのは、統計と検知の事実、検知ごとに最大 3 行の根拠のログ行(1 行 300 文字まで)です。
• キー・トークン・パスワードなどの秘密とメールアドレスは、送る前に伏せ字にします。
• IP は、203[.]0[.]113[.]9 のように無害化した形で渡します。「実際の IP を渡さない(仮名にする)」にチェックを入れると、ip-001 のような仮名に置き換えます。

「LLM で分析」タブの「送る内容を確認」を押すと、送る全文を見られます。この操作では何も送りません。「LLM で分析する」を押したときに、初めて送ります。

• ログの内容は攻撃者が書けます。AccessScope は、AI への指示に見える文字列を検知として報告して、LLM の出力は信頼しない引用として表示します。LLM が検知を実際より深刻に読むこともあるので、結論は根拠のログ行で確かめてください。
• claude と opencode は、AccessScope が道具(コマンドの実行やファイルの読み取り)を止めて起動します。codex と agy は道具を止められないので、設定に出る確認にチェックを入れる必要があります。root でも LLM の分析を使えますが、LLM は root の権限で動くので、権限のないユーザーでの実行をお勧めします(root で動いている間、設定に注意を出します)。

8. コマンドで使う

Server Edition のようにコマンドだけの環境や、cron で定期的に回したいときは、accessscope コマンドを使います。画面と同じエンジンなので、見つかる検知は同じです。

accessscope discover
accessscope scan --auto --since 7d --report report.md
accessscope scan /var/log/nginx/access.log /var/log/auth.log

cron で毎日回す

accessscope scan --auto --since 24h --since-last --new-only --fail-on medium

前回の実行になかった検知だけを表示して、新規の検知が中以上のときだけ、終了コード 3 になります。--llm なしの診断は、root でも動きます。

suppress.toml の書き方

除外ルールは ~/.config/accessscope/suppress.toml に書きます。このファイルがあれば、自動で読みます。

[[rule]]
reason  = "office"
ip      = ["203.0.113.0/28"]
expires = 2027-03-31

[[rule]]
reason      = "uptime monitor"
ua_prefix   = ["Mozilla/5.0 (compatible; UptimeRobot"]
path_prefix = ["/healthz"]

• ルールは、書いたすべての項目に一致したリクエストに当たります。reason は必須で、すべての報告に出ます。expires を過ぎたルールは適用されません。
• 深刻度が「高」の検知は、ルールに allow_high = true がないと外れません。
• User-Agent とパスはクライアントが書ける値です。IP を書かずに、それらだけで指定したルールは、攻撃・認証・Web シェルなどの検知を外せません。

9. できないこと

• 見えるのは、ログに残った事実だけです。リクエストの本文、応答の中身、アプリケーションの内部状態や、回転して消えた期間は分かりません。検知がないことは、安全の証明ではありません。
• 検知は「試みがあった」という意味で、成功した証拠ではありません。User-Agent は自己申告で、偽装できます。
• 複数のログにまたがる連鎖は、アドレスが同じという事実だけを根拠にします。NAT やプロキシの背後では、無関係な人が同じアドレスに見えます。内部のアドレス(リバースプロキシや Docker のゲートウェイ)は多数のクライアントをまとめた行なので、連鎖には入れません。成功の兆候のない連鎖は、深刻度が低になります。
• 「見慣れない接続元のログイン」は、そのログにとって見慣れないという意味で、不正とは限りません。「ふだんとの違い」は変化を示すだけで、攻撃とは限りません。
• AWS ALB と CloudFront のログは、AWS の文書の定義に沿って作った行で試していて、実際の AWS の出力では試していません。

10. 困ったとき

「いまは読めないログ」に出てくる

権限が足りないときの表示です。AccessScope は、権限を上げて読むことをしません。次のどれかで対処してください。

• ファイルのログは、権限のあるユーザーで起動するか、ログのコピーを「ファイルを選ぶ」で選びます。
• Linux の journald は、root、または adm・systemd-journal・wheel グループのユーザーで起動します。
• macOS の統合ログは、admin グループのユーザーで起動します。

「診断できるログが見つかりませんでした」と出る

理由が文で表示されます。たとえば「Web サーバ(Apache・nginx など)のログがありません」のように出ます。Mac では、SSH の記録がないときに「リモートログイン(SSH)が切れている可能性があります」と出ます。表示される「ファイルを選ぶ」「LLM で探す」「ほかの場所を指定する」で、次の手を試せます。どこを調べたかは、閉じてある「くわしい探索結果」を開くと分かります。

「Docker のログは読めませんでした」と出る

Docker が動いていない、Docker が見つからない、権限がない、Docker がエラーを返した、のどれかです。権限がないときは、Docker を使えるユーザーで AccessScope を起動してください。AccessScope は、権限を上げて読み直すことも、docker グループへの参加を求めることも勧めることもしません。docker グループの権限は、ホストの root と同等だからです。

「ログとして読めませんでした」と出る

選んだファイルから、1 行も解析できなかったときの表示です。そのファイルは診断の対象にならず、どこにも送られません。対応しているログの種類かどうかを確かめて、選び直してください。

「LLM で分析する」が押せない

ボタンの近くに理由が出ます。「LLM 連携はオフです」と出たら、設定で有効にします。「使う LLM が選ばれていません」と出たら、設定で選びます。root で起動しているときや、使う LLM のコマンドが端末に入っていないときも、使えません。

アクセス元がプロキシの IP ばかりになる

リバースプロキシや CDN の背後にあるログでは、アクセス元がプロキシの IP になることがあります。初期値の「自動」では、記録された接続元が内部のアドレス(リバースプロキシや Docker のゲートウェイなど)の行に限って、X-Forwarded-For からクライアントの IP を決めます。外部から直接来た行は、記録された接続元のままです。ヘッダの値は偽装できるので、この方法で決めた IP は、確認済みのクローラとしては扱いません。止めたいときは、設定の「解析」で「使わない」を選びます。ほかに、右から数えて信頼できる中継でない最初のアドレスを使う方法と、いちばん左のアドレスを使う方法も選べますが、この値はクライアントが書き換えられるので、自分で管理している信頼できる中継の背後でだけ使ってください。次の診断から有効になります。