目次
リモートルールセットの安全性は、変更できる内容から確認する
rule-providers 自体はルールファイルにすぎず、アカウントのパスワードを直接読み取ることはできません。ただし、ドメインを直接接続、プロキシ、拒否のどれへ流すかは変更できます。入手元が不明で、自動更新され、ロールバックもできないルールでは、機密性の高いリクエストが知らないうちに誤った出口へ送られる危険があります。
Rule Provider は、ドメインをプロキシ、直接接続、拒否のどれへ流すかを決めます。対象範囲が広すぎる DOMAIN-SUFFIX ルールを先に置くと、銀行、会社の管理画面、社内ログインが突然見知らぬノードを通る可能性があります。リスクはルートの変更から生じるため、ルールファイルにパスワードを読み取る権限は不要です。
接続記録に想定外のポリシーが表示された場合は、まず以前のキャッシュへ戻して既存の接続を切断し、その後ルールファイルを比較します。異常が起きた時刻、Provider 名、一致した項目、最終出口をまとめて確認することで、メンテナーが誤ってドメインを含めたのか、ローカルの順序に問題があるのか、リモートの内容が置き換えられたのかを区別できます。
まずリポジトリとコミットまで追跡し、その後 raw アドレスをコピーする
追加前に答えられる必要があること
- この raw ファイルが属する公開リポジトリとメンテナー
- リポジトリのコミット履歴がルールのテーマと一致しているか
- ダウンロード内容が YAML/MRS テキストであり、ログインページ、スクリプト、短縮リンクからのリダイレクトではない
- 現在の設定で、前回ダウンロードしたローカルファイルを保持できるか
- エラー発生時に、この Provider だけを無効にする方法が分かるか
ブランチのアドレスはコミットのたびに内容が変わるため、信頼済みで更新が必要なルールに適しています。コミットハッシュのアドレスは内容が固定され、銀行や会社への直接接続など、変更が少なく影響の大きいルールに適しています。二つは併用でき、すべての入手元を一時間おきの更新に設定する必要はありません。
URL、形式、ローカルパス、更新時刻をすべて確認できるようにする
rule-providers:
research:
type: http
behavior: domain
format: yaml
url: https://raw.githubusercontent.com/OWNER/REPO/COMMIT/rules.yaml
path: ./ruleset/research.yaml
interval: 86400
rules:
# REPLACE_WITH_POLICY 必须换成当前配置中已经存在的策略组
- RULE-SET,research,REPLACE_WITH_POLICY
- MATCH,DIRECTOWNER、REPO、COMMIT、REPLACE_WITH_POLICY はすべてプレースホルダーであり、コピー後にそのまま有効にすることはできません。確認済みのリポジトリ、固定コミット、既存のポリシーグループへ置き換えてください。
behavior と format はリモートの内容と一致させ、path にはカーネルが書き込める場所を指定する必要があります。ルール参照を MATCH より前に置く場合も、会社のネットワーク、LAN、直接接続が必須の高優先度ルールを避けてください。
更新に成功したら、ルール数と更新時刻を確認し、よく知っているドメインを数件選んで一致を確認します。画面に「更新完了」と表示されただけでは、現在の実行時設定が新しいファイルを実際に参照していることを証明できません。
重要なルールを更新する前に、diff で変更内容を確認する
RULE_URL='https://raw.githubusercontent.com/OWNER/REPO/COMMIT/rules.yaml'
curl -L --fail --show-error -o rules.new.yaml "$RULE_URL"
sha256sum rules.new.yaml
diff -u rules.last.yaml rules.new.yaml | lessmacOS では sha256sum の代わりに shasum -a 256 を使用できます。ハッシュで分かるのは、二つのファイルが同じかどうかだけで、内容自体の信頼性は証明できません。実際に確認すべきなのは、追加項目と削除項目、リポジトリのコミット説明、ルールのテーマが一致しているかどうかです。
ファイルが数千行から突然数十行へ減った場合、先頭に <!doctype html> が現れた場合、動画用ルールへ多数のアカウントや銀行ドメインが一度に追加された場合は、自動更新を停止してください。
すでに誤ったポリシーを通った場合は、まずファイルをロールバックしてから、アカウントを処理する
Provider の更新直後に異常が起きた場合は、まず以前のルールを復元して既存の接続を切断します。ルーティングが復旧してから、機密性の高いリクエストが実際に誤った出口を通ったか判断してください。
異常発生時の対処
この Provider の更新を停止する
以前のキャッシュへ戻すか、RULE-SET の参照を一時的に削除します。
設定を再読み込みして接続を切断する
新しいリクエストは元のポリシーへ戻ります。既存のセッションは出口を自動では変更しません。
リポジトリの変更内容と比較する
項目の誤収録、アドレスの移行、形式の変更、入手元の検証不能のどれに該当するか確認します。
機密性の高いアカウントを確認する
ログインリクエストが想定外の出口を通った場合は、ログイン履歴を確認し、リスクに応じて認証情報を変更してください。
固定コミットまたは別の入手元へ切り替える
説明できないリモートファイルでは、自動更新を再び有効にしないでください。