（メールの文字コードのデコードについて、最後に追記 2023.08.07)
久々に詐欺メールが届いたので、メールヘッダの見方などのほぼ個人的なメモ。
Fakeメールが来たのだけれど、SPFのチェックが通っているのが不思議。
メールは、secureserver.netというホスティングサービスのIPアドレスから送信されていて、X-Senderで使っているドメインのMXレコードは、smtp.secureserver.netになっている。
SPFのチェック内容を見みると、stuff@xxx.comと、送信したsecureserver.netのIPアドレスでチェックしているようにみえる。
どうも、SPFのチェックで Fromのドメインではなくて、X-Senderのドメインでチェックしている模様。
もしかして、このメールを送信したメールサーバは、MAIL FROM:に X-Senderを使う仕様になっているのだろうか？
X-SECURESERVER-ACCT: stuff@xxx.com
X-Originating-IP: xx.xx.145.155
From: [実在のメールアドレス]
X-Sender: stuff@xxx.com (MX=smtp.sss.net)
Reply-To: [Fromに一致する名前] <xxxxxx@yopmail.com>
To: [実在のメールアドレス]
Me: SMTPの接続元のIPアドレスがSMTP Mail From:（いわゆる envelope from）のドメインのSPFレコードに含まれていればパスします。
YK:X-Sender: はどこかで誰かが SMTP Mail From: の値をコピーしているのでしょう。
Me:素人質問で恐縮なのですが、SMTP Mail Fromは、ヘッダーに残りますか？
YK:メールサーバの実装によりますが、よくあるのは Return-Path: でしょうか。
Me:ありがとうございます。確かに、Return-Path：に入っていました。
Me:これで回避できるとなると、なかなかしんどいですね。
YK:ヘッダ From: の詐称チェックは DKIM 使うことになるかなぁ。
-
secureserver.net : GoDaddy.com,LLC
-
ほぼ同じ手法(SANS ISC InfoSec Forums)
基本ツール
nslookup
nslookup hostmane # DNS参照
nslookup ip # DNS逆引き
nslookup -type=MX domain(aaaa.com) # MXレコード
nslookup -type=TXT domain(aaa.com) # SPF and others
- v=spf1ip4:xx.xx.135.0/24
traceroute
TCP tracerouteがよいのだけれど、WSLではRaw Socketが利用できない模様。
自分のグローバルIPアドアレス
サービス関係
メールヘッダの解析ツール
Tools for Reading Email Headers
Full Email Headers can normally be quite lengthy and overwhelming. The following are great tools that will assist you in dissecting your email header:
-
Microsoft Remote Connectivity Analyser
- ヘッダーの詳細を見るのに便利そう
- Paste the email headers details into the message analyser field provided and click Analyze headers to see the report.
- 関連するツールセット
-
Google Apps Toolbox – Message Header
- SPF/DKIMをチェックしてくれるがよい感じ
- Simply copy your email header into the Message Header Analyser and Google will translate the Email Header into a format that is more simple to read.
To locate your Email Headers, take a look at this article: support.protectedservice.net/kb/locate-email-headers/
Microsoft
Google Admin Toolbox
- ブラウザの問題をデバッグする
- Browserinfo は、クライアントサイドの情報を取得するためのブラウザベースのデバッグツールです。インターネット上での動作に影響を与える可能性のある情報を明確に得ることができます。
- Useragent はユーザー エージェント文字列を分析するツールです。
- DNS の問題を確認する
- Check MX は手軽に使える DNS 確認ツールで、MX レコードの設定におけるよくある間違いをチェックできます。
- Dig は Unix の dig コマンドに相当するウェブベースのツールとして使用できます。
- HAR ファイルとログファイルを分析します
- HAR Analyzer では、取得した HAR ファイルを分析できます。
- Log Analyzer では、Google のサービスで生成されたログファイルを分析することができます（Chrome、Google Workspace Sync for Microsoft Outlook、Google Cloud Directory Sync を含む）。
- Log Analyzer 2 は、Google のサービスで生成された大きなログファイルを開き、一般的な問題を診断するツールです。
- メールの問題を調査する
- Messageheader では SMTP メッセージ ヘッダーを分析でき、配信の遅延の根本的な原因を特定するために役立てられます。誤って設定されたサーバーやメールのルーティングに関する問題を検出できます。
- その他のデバッグツール
- その他のツール は Google Workspace サービスのデバッグに役立ちます。
- Encode / Decode はウェブ関連の問題をデバッグするのに役立つエンコードとデコードの機能を提供します。
- スクリーン レコーダー を使用すると、画面キャプチャと音声を記録できます。
SPFレコードの確認
dig -t TXT <ドメイン>
Free online network tools
-
-
Domain Dossier
- Investigate domains and IP addresses. Get registrant information, DNS records, and more—all in one report.
-
Domain Check
- See if a domain is available for registration.
-
Email Dossier
- Validate and troubleshoot email addresses.
-
Browser Mirror
-
See what your browser reveals about you.
-
Ping
- See if a host is reachable.
-
Traceroute
- Trace the network path from this server to another.
-
NsLookup
- Look up various domain resource records with this version of the classic NsLookup utility.
-
AutoWhois
- Get Whois records automatically for domains worldwide.
-
AnalyzePath
- Do a simple, graphical traceroute.
-
ipinfo
netcraft
URLのチェックは、結構下の方になりました。
ここでは、書ききれないモリモリの情報が確認できる。
（自組織の）Webサイトのチェック
無料で自分のウェブサイトの脆弱性をスキャンしてくれる「Probely」レビュー、有料プランはレポート出力なども可能
AWS IAM Access Analyzer を使用する
## 危ないサイトの閲覧
直接URLを参照してIPアドレスを残したくないとき、攻撃が埋め込まれている可能性があるときに、URLをこれらのサーバー経由で閲覧する
- gred (securebrain)
- aguse Gateway(isquare co.,ltd ，agusenet co.,ltd.)
- SecURL (nu-face hoting service)
メールヘッダの取得
Gmailの場合は、メッセージソースということで、メール全文が表示される。
ブラウザの通信のモニタ
SDL的なもの
オープンソースプロジェクトのセキュリティを1発で自動評価してくれる「Security Scorecards」が登場
メールセキュリティの基本
DMARC, ARC, MIMI
-
DMARC: Domain-based Message Authetication, Reporting, and Conformace
- SPF/DKIM認証のエラー情報・統計情報のレポーティング機能
- SPF/DKIM検証失敗メールの取り扱いを送信側が指定する機能（受信側はポリシーに基づいて取り扱い方法を決定）
- none:処理方式を指定しない
- quarantine:隔離する
-reject:受信拒否する
- DMARCのアラインメント
- SPF/DKIMでは、送信元ドメインと検証用ドメインは無関係でもよい（第三者署名を許可）
- 偽の署名が可能
- DMARCでは第三者余命は認証失敗(fail)となる
- SPF/DKIMでは、送信元ドメインと検証用ドメインは無関係でもよい（第三者署名を許可）
-
ARC: Authenticated Received Chain
- MLなどで再配送メールを正しく認証する仕組み（IETFなどで議論中？）
- Authentication-Resultsヘッダを辿ることで認証の連鎖を確認可能にする
- DMARCの問題
- 経由したサーバーごとにRecived:ヘッダが追加
- ヘッダの正当性が検証できない
- ARCヘッダ：再配送時にARC独自に再署名
- ARC-Seal: ARC関連ヘッダを十番ごとに連結したデータから生成される電子署名
- ARC-Message-Signeture: DKIMと同様の再署名情報
- ARC-Authentication-Result: Authentication-Results:ヘッダの保存に使用
- MLなどで再配送メールを正しく認証する仕組み（IETFなどで議論中？）
-
BMI: Brand Indicators for Message Identification
- BMIとは
- 送信ドメイン認証により認証されたドメインからのメールをわかりやすく受信者に提示するための仕組み
- 認証されたメールは、MUA(メールソフト）やWebメールで送信者のドメインに関連したロゴを表示
- MUAが参照する情報をメールヘッダに保存
- BMIの設定
- 送信ドメイン認証技術と同様にDNSを用いて情報を記述
- ロゴなどの情報をTXTレコードで示す
- 送信ドメイン認証技術と同様にDNSを用いて情報を記述
- BMIとは
SPF
- SPF認証結果
認証結果は次のものが存在する。
| 認証結果 | 意味 |
|---|---|
| None | SPFレコードが公開されていない |
| Neutral | SPFレコードが“?”として公開されている条件にマッチした |
| Pass | 認証処理に成功した |
| Fail | SPFレコードが公開されているが、認証に失敗した |
| SoftFail | SPFレコードが“~”として公開されている条件にマッチした |
| TempError | 一時的な障害で認証処理が失敗した |
| PermError | SPFレコードの記述に誤りがあるなどで認証処理に失敗した |
-
None
SPFレコードが公開されていないため、認証できなかったことを示す。送信ドメイン認証では送信元についての評価が下せないため、従来どおりスパムフィルタを通すなどしてメールの扱いを決定する。結果がNoneだったからといって、メールを即座に受信拒否すべきではない。 -
Neutral
送信ドメインのSPFレコードが、たとえば“v=spf1 ?all”のように定義されている場合、あるいは“v=spf1 +ip4:192.0.2.1 ?all”のようにレコードの末尾が“?all”と定義されていて、先立つ他の条件にマッチせず“?all”にマッチした場合、Neutralとなる。
RFCでは、NeutralはNoneと同じように扱うべきであるとされている。また、SoftFailよりは正当性が高いものとして扱う可能性があるとも説明されている。結果がNeutralだった場合には、メールを即座に受信拒否すべきではない。 -
Pass
送信元のIPアドレスがSPFレコードにマッチし、認証に成功した場合である。送信ドメインは認証されたと評価できる。しかし、送信元のドメインが認証されたとしても、そのメールの内容（本文等）についてはSPF認証結果が保証するものではないことには注意が必要である。迷惑メール送信者もSPFレコードを公開できるという現実を考慮し、認証されたドメインに対してホワイトリストやブロックリスト、また、ドメインのレピュテーションなどと組み合わせて、受信したメールの最終的な処理方法を決定すべきである。認証されたドメイン名によってホワイトリストやブロックリスト等の運用がより正確に行える。 -
Fail
SPFレコードが公開されているが、送信元のIPアドレスが“-”限定子の条件にマッチする場合である。SPFレコードを公開していない場合、また、“?all”や“~all”が末尾に設定されているSPFレコードが公開されているドメインからのメールに対しては、この結果は発生しない。つまり、送信元のドメインを偽称している可能性が非常に高いと見なすことができる。RFCにおいてはこの結果に従って通信中のSMTPセッションにおいて該当メールの受信拒否を行う場合、550番エラーの利用を勧めている。 -
SoftFail
SPFレコードが公開されており、送信元のIPアドレスが“~”限定子の条件にマッチする場合である。RFCでは、FailとNeutralの中間位の扱いをすべきであるとされている。結果がSoftFailである場合には、メールを即座に受信拒否すべきではない。 -
TempError
一時的な障害で認証処理が失敗した場合である。対応としては、メールを一時エラー（4XX）で受信拒否するか、そのまま受信することになる。受信した場合は、少し厳しく扱うべきである。 -
PermError
SPFレコードは公開されているが、SPFレコードの記述に誤りがある場合などにPermErrorとなる。この結果であっても、永続的な受信拒否をすべきではない。
一般的に、SPF認証はインターネットに直接アクセスしているMTAで実施する。RFCでは、SPF認証はSMTPの通信中に実施すべきとされており、さらに、SPFの認証結果に従って何らかのアクション（受信拒否など）を行う場合は、メールを受信し終わった後ではなく、そのSMTP通信中に実施することを勧めている。そうすることで、メールを受信したのち、偽称されている送信者に対してエラーメールを返送することを防ぐことができる。
認証結果によって通信中のSMTP接続においてメールの受信拒否を行わない場合、認証結果は該当のSMTP通信で配送されてきたメールのヘッダに記録することを想定している。RFC4408では”Received-SPF”ヘッダを利用してメールに記録することが勧められているが、その後の検討により、送信ドメイン認証（SPF、DKIM、Sender ID等）やその他電子メールに関連する認証結果を記録するヘッダとして、Authentication-Resultsヘッダを利用することがRFC 5451にて標準化されたため、現在では、Authentication-Resultsヘッダに記録することが実装における主流となっている。それぞれのヘッダの書式については、それぞれのRFCを参照されたい。
None
GmailのSPF
Google 確実なメール配信となりすまし防止（SPF）
ステップ 1: SPF の TXT レコードを作成する
SPF の TXT レコードは、自社のドメインに代わってメールを送信できるメールサーバーを定義するものです。
1 つのドメインで設定できる SPF の TXT レコードは 1 つだけです。ただし、ドメインの TXT レコードには、ドメインのメールを代理送信できるサーバーとドメインを複数指定できます。
- TXT レコードの内容
組織からのすべてのメールが G Suite から送信されている場合は、TXT レコードに次のテキスト行を使用します。- v=spf1 include:_spf.google.com ~all
G Suite に加えて、次のいずれかの方法でメールを送信している場合は、カスタムの SPF TXT レコードを作成する必要があります。
- G Suite 以外のサーバーからもメールを送信している。
- サードパーティのメール プロバイダを利用している。
- ウェブサイトで自動メール生成サービス（「お問い合わせ」フォームなど）を使用している。
gmailに直打ちできるのか？
Gmail(SMTP)経由でメール送信する --> 送信できた
Net::SMTP - SMTP(Simple Mail Transfer Protocol)クライアント
マルウエアチェックなど
Virus totalも良いけれど、Joessandboxは結構よいかもしれない
https://www.joesandbox.com/
メールの文字コードのデコード
nkfで結構いける
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
nkf -mB