mattkeeley/spoofy権威あるSPFおよびDMARCレコード分析と、カスタムの実世界でテストされたスプーフロジック、およびオプションのDKIM列挙を使用した一括ドメインスプーフィング可能性チェッカー。
Spoofy は、SPF および DMARC レコードに基づいて、ドメインのリストがスプーフィング可能かどうかをチェックするプログラムです。「ドメインがスプーフィング可能かどうかをチェックするツールがなぜもう一つ必要なのか？」と思われるかもしれません。
しかし、Spoofy は他とは異なります。その理由は以下の通りです：
- カスタムで手動テスト済みのスプーフィングロジック（推測や憶測ではなく、実世界のテスト結果）
- 標準に基づくレコード検出：RFC 7208 の SPF 評価と RFC 9989 の DMARC ツリーウォーク（サブドメイン用の
sp/npを含む）- 共有キャッシュリゾルバとフェイルオーバー（1.1.1.1、8.8.8.8、9.9.9.9）による正確な一括ルックアップ
- SPF DNS クエリおよび void ルックアップカウンタ、さらに未登録の SPF include ドメインの検出
- API 経由のオプションの DKIM セレクタ列挙
Spoofy には Python 3.9+ が必要です。PyPI からインストールしてください：
pip3 install spoofy
spoofy -d example.com
または、クローンから pip3 install -r requirements.txt を実行し、spoofy の代わりに ./spoofy.py を使用して実行します。使用方法は以下の通りです：
Usage:
spoofy -d [DOMAIN] -o [stdout, xls or json] -t [NUMBER_OF_THREADS] [--dkim] [--dns-server IP]
OR
spoofy -iL [DOMAIN_LIST] -o [stdout, xls or json] -t [NUMBER_OF_THREADS] [--dkim] [--dns-server IP]
Options:
-d : Process a single domain.
-iL : Provide a file containing a list of domains to process (blank lines and # comments are skipped).
-o : Specify the output format: stdout (default), xls, or json.
-t : Set the number of threads to use (default: 4).
--dkim : Enable DKIM selector enumeration via API (optional).
--dns-server : Query this resolver instead of 1.1.1.1, 8.8.8.8 and 9.9.9.9.
Examples:
spoofy -d example.com -t 10
spoofy -d example.com --dkim
spoofy -iL domains.txt -o xls
spoofy -iL domains.txt -o json --dkim
（スプーフィング可否テーブルには、DKIM 修飾子を除き、受信トレイへの配信に影響を与える SPF および DMARC 設定のすべての組み合わせが記載されています。） こちらからダウンロード
| コード | 結果 | SPOOFING_POSSIBLE |
|---|---|---|
| 0 | スプーフィング可能 | true |
| 1 | サブドメインのスプーフィング可能 | true |
| 2 | 組織ドメインのスプーフィング可能 | true |
| 3 | スプーフィングが可能な場合がある（p=quarantine で pct < 100） | null |
| 4 | スプーフィングが可能な場合がある（メールボックス依存） | null |
| 5 | 組織ドメインのスプーフィングが可能な場合がある（メールボックス依存） | null |
| 6 | サブドメインのスプーフィングが可能な場合がある（メールボックス依存） | null |
| 7 | サブドメインのスプーフィング可能、組織ドメインのスプーフィングが可能な場合がある | true |
| 8 | スプーフィングは不可能 | false |
| 9 | 判定不能（DNS ルックアップが失敗） | null |
判定結果は、ドメインの SPF all メカニズムと、DMARC の p、sp、aspf タグがレコードに書かれている通りのテスト済みコードです。spoofy/master_table.py はスプレッドシートをデータとして保持しており（スプレッドシート変更後は python3 -m spoofy.master_table で書き換えます）、test.py はすべての行が再現されることを確認します。テーブルでカバーされていない入力は以下のように処理されます：
aspf はあるが sp がない強制 p（24 の未テストの組み合わせ）：sp は p にデフォルト設定されるため、sp を明示したテスト済みの行が使用されます。_dmarc レコードを持たないサブドメイン）：親の SPF および DMARC レコードに対してテストされたサブドメインの結果で、サブドメインが存在しない場合は sp の代わりに np を使用します。p=quarantine で pct が 100 未満：コード 3。サンプリングされないメールは p=none になるためです。p=reject の場合、サンプリングされないメールは依然として隔離されるため、pct は判定を変えません。t=y（RFC 9989 テストモード）：ポリシーはルックアップ前に 1 レベル下がります（reject から quarantine、quarantine から none）。スプーフィング可否テーブルの作成には、関連するすべての SPF および DMARC 設定をリストアップし、それらを組み合わせ、多数の米国政府ドメインに対して Spoofy の初期バージョンを使用して SPF および DMARC 情報を収集することが含まれました。SPF と DMARC の組み合わせがスプーフィング可能かどうかのテストは、Microsoft 365 を使用して emailspooftest のメールセキュリティペネトレーションテストスイートで行われました。ただし、初期のテストは Protonmail と Gmail を使用して実施されましたが、これらのサービスは結果に影響を与える逆引きルックアップチェックを利用していることが判明し、特にサブドメインのスプーフィングテストで問題となりました。その結果、メールの処理をより細かく制御できる Microsoft 365 がテストに使用されました。
Microsoft 365 を使用した初期テスト後、メール内のバナーの処理の違いにより、一部の組み合わせが Protonmail と Gmail を使用して再テストされました。Protonmail と Gmail は、スプーフィングされたメールをバナー付きで受信トレイに、またはバナーなしでスパムに配置することがあり、Spoofy を使用すると一部の SPF および DMARC の組み合わせが「メールボックス依存」と報告される原因となりました。対照的に、Microsoft 365 は両方の条件をスパムに配置します。テストとデータ収集プロセスは完了するまでに数日を要し、その後、優れたマスターテーブルが作成され、Spoofy のスプーフィング可否ロジックの基礎として使用されました。
このツールはテストおよび学術目的のみを目的としており、厳格な同意が得られた場合にのみ使用できます。違法な目的で使用しないでください！適用されるすべての地方、州、および連邦法を遵守することはエンドユーザーの責任です。開発者は一切の責任を負わず、このツールおよびソフトウェアによって引き起こされた誤用や損害に対して責任を負いません。
このプロジェクトは Creative Commons Attribution-NonCommercial 4.0 International License の下でライセンスされています - 詳細は LICENSE ファイルを参照してください