日常的なセキュリティチェックツールなど（元々はメールヘッダのチェック）

14687 ワード
Security mail mail テキストリンク

久々に詐欺メールが届いたので、メールヘッダの見方などのほぼ個人的なメモ。

Fakeメールが来たのだけれど、SPFのチェックが通っているのが不思議。
メールは、secureserver.netというホスティングサービスのIPアドレスから送信されていて、X-Senderで使っているドメインのMXレコードは、smtp.secureserver.netになっている。
SPFのチェック内容を見みると、[email protected]と、送信したsecureserver.netのIPアドレスでチェックしているようにみえる。
どうも、SPFのチェックで Fromのドメインではなくて、X-Senderのドメインでチェックしている模様。
もしかして、このメールを送信したメールサーバは、MAIL FROM:に　X-Senderを使う仕様になっているのだろうか？

X-SECURESERVER-ACCT: [email protected]
X-Originating-IP: xx.xx.145.155 
From: [実在のメールアドレス]
X-Sender: [email protected]   (MX=smtp.sss.net)
Reply-To: [Fromに一致する名前] <[email protected]>
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 使うことになるかなぁ。

基本ツール

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

  • 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

SPFレコードの確認

dig -t TXT

Free online network tools

  • 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

https://ipinfo.io/

netcraft

URLのチェックは、結構下の方になりました。
ここでは、書ききれないモリモリの情報が確認できる。

（自組織の）Webサイトのチェック

無料で自分のウェブサイトの脆弱性をスキャンしてくれる「Probely」レビュー、有料プランはレポート出力なども可能
AWS IAM Access Analyzer を使用する

##　危ないサイトの閲覧

直接URLを参照してIPアドレスを残したくないとき、攻撃が埋め込まれている可能性があるときに、URLをこれらのサーバー経由で閲覧する

メールヘッダの取得

Gmailの場合は、メッセージソースということで、メール全文が表示される。

ブラウザの通信のモニタ

SDL的なもの

オープンソースプロジェクトのセキュリティを1発で自動評価してくれる「Security Scorecards」が登場

メールセキュリティの基本

DMARC, ARC, MIMI

  • <5分でわかった気になる解説シリーズ>DMARC,ARC,MIMI

  • DMARC: Domain-based Message Authetication, Reporting, and Conformace

    • SPF/DKIM認証のエラー情報・統計情報のレポーティング機能
    • SPF/DKIM検証失敗メールの取り扱いを送信側が指定する機能（受信側はポリシーに基づいて取り扱い方法を決定）
      • none:処理方式を指定しない
      • quarantine:隔離する
        -reject:受信拒否する
    • DMARCのアラインメント
      • SPF/DKIMでは、送信元ドメインと検証用ドメインは無関係でもよい（第三者署名を許可）
        • 偽の署名が可能
      • DMARCでは第三者余命は認証失敗(fail)となる

  • ARC: Authenticated Received Chain

    • MLなどで再配送メールを正しく認証する仕組み（IETFなどで議論中？）
      • Authentication-Resultsヘッダを辿ることで認証の連鎖を確認可能にする
    • DMARCの問題
      • 経由したサーバーごとにRecived:ヘッダが追加
      • ヘッダの正当性が検証できない
    • ARCヘッダ：再配送時にARC独自に再署名
      • ARC-Seal: ARC関連ヘッダを十番ごとに連結したデータから生成される電子署名
      • ARC-Message-Signeture: DKIMと同様の再署名情報
      • ARC-Authentication-Result: Authentication-Results:ヘッダの保存に使用

  • BMI: Brand Indicators for Message Identification

    • BMIとは
      • 送信ドメイン認証により認証されたドメインからのメールをわかりやすく受信者に提示するための仕組み
      • 認証されたメールは、MUA(メールソフト）やWebメールで送信者のドメインに関連したロゴを表示
      • MUAが参照する情報をメールヘッダに保存
    • BMIの設定
      • 送信ドメイン認証技術と同様にDNSを用いて情報を記述
        • ロゴなどの情報をTXTレコードで示す

SPF

  1. 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にコマンドラインからメールを送る

Gmail(SMTP)経由でメール送信する --> 送信できた

Net::SMTP - SMTP(Simple Mail Transfer Protocol)クライアント