URLチェック・安全確認
クリックされる前に、リンクやサイトのフィッシング・マルウェア判定を確認します。
URLレピュテーションとは
URLレピュテーションとは、特定のWebアドレスについて記録された情報に基づき、セキュリティシステムが与える信頼度です。マルウェアの配布、フィッシングページのホスト、スパムへの利用などで決まります。ブラウザ、メールプロバイダー、セキュリティフィルターはこのシグナルを参照し、リンクを許可するか、警告するか、ブロックするかを判断します。同じ診断はWebサイトの評価確認にも使えます。サイトのトップページのアドレスを入力すれば、各ソースがサイト全体をどう評価しているかがわかります。
結果の見方
| 判定 | 意味 | 対処法 |
|---|---|---|
| 掲載 | ホストかそのWebサーバーのIPが、応答した脅威ブロックリストの1つ以上に記録されています。 | 各ソースの根拠を開き、根本の乗っ取りを直してから、各運営者の審査手続きに従ってください。 |
| 要注意 | 掲載はありませんが、URLにIP直指定のホスト、punycode、埋め込まれた認証情報、HTTPSなしといった構造上の警告サインがあります。 | 結果に表示された警告サインを読み、リンクを信頼する前に、行き先が名乗っているとおりか確かめてください。 |
| 正常 | 応答したソースにアドレスの記録はなく、URLに構造上の警告サインもありません。 | 対応は不要ですが、作られたばかりの悪意あるURLにはまだ履歴がなく、正常でも安全の証明にはなりません。 |
| 正常(一部ソースは応答なし) | ドメイン用ブロックリストは応答しませんでしたが、サイトのサーバーIPは確認でき、正常でした。 | 部分的な証拠として扱い、重要なら後で再実行してください。 |
| 不明 | どのソースも応答せず、判断できる証拠がありません。 | 正常ではなく不明として扱い、少し待って再度お試しください。 |
| 無効なURL | アドレスを解析できませんでした。ドメインだけの入力も受け付け、自動でhttps://を付けます。 | https://example.com/pageのようにスキームも含めます。 |
この診断で証明できること
この診断で証明できるのは、公開されている脅威ソースがアドレスについて現在何を記録しているかと、URLに4つの構造上の警告サインのどれかがあるかです。この2つは種類の違う証拠で、結果ではあえて分けて示します。掲載は履歴の記録で、警告サインは目の前のリンク自体の性質です。
証明できないのは、リンクが安全であることです。ブロックリストは過去を振り返るもので、標的型フィッシングのURLは作られて数時間しかたっておらず、どこにも載っていないのが普通です。正常の判定は記録された証拠がないということで、確かに役立ちますが、信頼できることとは違います。
自社ドメインを名乗るリンク付きメールを止める
確認すべきリンクの多くはメールで届きます。信じてしまうのは、受信者が信頼するブランドからのメールに見えるからです。DMARCをポリシー強化の状態で公開すれば、攻撃者が自社ドメインを名乗ってメールを送ること自体を止められます。PalisadeはDMARCの集計レポートを優先順位付きのワークフローに変えます。担当者はドメインを使う全送信元の特定、アライメント失敗の調査、提案されたレコード変更のレビューを進め、根拠をもって各ドメインのポリシーを強化できます。
MSP向けにはマルチテナントで設計。全顧客ドメインのチェック、修正、ポリシー強化を1つの管理画面で行えます。顧客ドメイン単位の料金は管理数が増えるほど単価が下がり、顧客のメール送信量は計測しません。
怪しいリンクが届きましたか? フィッシングリンクチェックなら、クリックしても安全かをわかりやすく判定し、すでにクリックした場合の対処も示します。
リンク確認 →関連する評価チェック
メール認証ナレッジベース
Webサイトの評価はどう確認しますか?
サイトのアドレスを入力して診断を実行します。Webサイトの評価確認はURLチェックと同じ診断を、サイトのルートアドレスに対して行います。ホストを、メールプロバイダーやセキュリティフィルターが使う脅威インテリジェンスのブロックリストで照会し、WebサーバーのIPも確認します。ドメインだけを入力すると、自動でhttps://のアドレスとして扱います。メールボックスプロバイダーが送信ドメインに与える信頼のシグナルを知りたいときは、ドメインレピュテーション確認を使ってください。
この診断は実際に何を確認しますか?
常に2つの層を実行します。1つ目はURL自体の構造で、4つの警告サインを調べます。ホスト名の代わりのIPアドレス直指定、似た文字を偽装できるpunycode(xn--)のホスト、@の前に埋め込まれた認証情報、HTTPSなしの4つです。2つ目は、ホストをドメイン用の脅威ブロックリストで、サイトのWebサーバーのIPをIP用ブロックリストで照会します。3つ目の層であるabuse.ch運営のURLhausマルウェアDBは、abuse.chのキーが設定されている場合だけ実行し、それ以外は「未確認」と表示します。
「要注意」の判定はどういう意味?
どのブロックリストにもアドレスの掲載はないものの、URL自体にpunycodeのホストや埋め込まれた認証情報など、構造上の警告サインが1つ以上あるという意味です。この組み合わせは注意深く見る価値があります。掲載は攻撃より遅れるため、作られたばかりのフィッシングページはまだどこにも載っていないのが普通です。「要注意」は調べるきっかけで、悪意ありと確定した判定ではありません。
結果が正常なら、リンクは安全と言えますか?
いいえ。これが最も理解しておくべき限界です。ブロックリストは履歴に基づくため、標的型フィッシング用に1時間前に作られたURLには履歴がなく、正常と判定されます。正常の結果は、アドレスについて既知の記録がないという意味で、行き先が信頼できるという意味ではありません。予期しないリンクは、評価の診断だけでなく、どこから届き、何を求めているかで判断してください。
URLhausのチェックが「未確認」なのはなぜ?
URLhausの照会にはabuse.chの認証キーが必要ですが、現在このサイトにはキーを設定していません。そのため、正常と主張せず「未確認」と表示します。不明として扱ってください。構造とブロックリストの層は実行しており、上の判定はそれらに基づいています。
Webサイトの評価スコアは出ますか?
いいえ。あえて出していません。スコアを1つの数値で返すツールもありますが、算出の経緯が見えません。このチェックは判定とその根拠を返します。どのソースが応答したか、どこに記録があったか、URL自体にどんな構造上の警告サインがあるかです。数値では、3つのブロックリストのうち2つが応答しなかったことはわからず、その違いで結果の価値は変わります。
URLとドメインのレピュテーションの違いは?
答える問いが違います。URLレピュテーションは、特定のWebアドレスがマルウェアやフィッシングに関係しているかを問う、リンクのセキュリティの問題です。ドメインレピュテーションは、メールボックスプロバイダーがドメインからのメールをどう扱うかを問う、送信者の到達率の問題です。セキュリティ上はまったく問題のないドメインでも送信の評価が低いことがあり、その逆もあります。
メールでリンクが届いた。これとフィッシングリンクチェックのどちらを使う?
フィッシングリンクチェックを使ってください。同等のチェックを実行しつつ、クリックしても安全か、すでにクリックしたらどうするかという受信者の疑問に、わかりやすく直接答えます。このページは別の用途向けで、自社のサイト、リンク先のサイト、調査中のサイトの確認に使います。
プロバイダーがメール内のリンクを確認する理由は?
リンクが攻撃の本体であることが多いからです。メールが認証をすべてパスしても、認証情報を盗むページへのURLが含まれていることがあるため、プロバイダーは送信者とは別にリンクを評価します。そのため、乗っ取られたサイトは、そこにリンクしている全員の到達率を気付かないうちに下げることがあります。
サイトが掲載されたので修復しました。次は?
再診断してどのソースにまだ掲載があるか確かめ、各運営者の解除手続きに従ってください。解除を認めるのは運営者で、診断ではできません。まず根本原因を直してください。乗っ取られたままのサイトの解除は一時的なものに終わります。
DMARC、SPF、DKIMのタグと仕組みを1か所でまとめて解説します。
DMARC
- vバージョン
- バージョンタグはDMARCレコードに必須で、値は「DMARC1」に限られます。値が正しくない場合やタグがない場合、DMARCレコードは無効とみなされ、無視されます。
- pポリシー
- DMARCポリシータグは、DMARCに失敗したメールについて3つの値を取ります。noneは隔離・拒否を求めず、quarantineは不審なメールとしての扱いを、rejectは受信拒否を求めます。最終的な処理は受信側が決め、p=noneでも別の仕組みで振り分けや拒否をする場合があります。集計レポートは、ruaタグで別途要求します。
- rua集計レポートの送信先
- 集計レポートの送信先を「mailto:」形式のURIで指定します。受信側のメールボックスプロバイダーがこの宛先に集計レポートを送ります。必須ではありませんが、省略するとレポートは届きません。
- ruf失敗レポートの送信先
- 失敗(フォレンジック)レポートの送信先を「mailto:」形式のURIで指定します。失敗レポートを送る受信側プロバイダーはここへ届けますが、送らない事業者も多くあります。このタグがないと失敗レポートは届きません。
- spspポリシー
- サブドメインのポリシーは、特に指定がない限り、前述のメインドメインのポリシータグ(p=)を継承します。指定できる値はドメインのポリシーと同じく「none」「quarantine」「reject」です。ただし、現在の運用ではあまり使われていません。
- adkimDKIMアライメント
- DKIM署名のアライメント、つまりDKIMのドメインとヘッダーFromの送信元ドメインとの一致を指定するタグです。値は「r」(relaxed)と「s」(strict)です。既定の「r」はドメインの部分一致を許容し、「s」はドメインの完全一致を求めます。
- aspfSPFアライメント
- SPFアライメント、つまりSPFのドメイン(送信元)とヘッダーFromのドメインとの整合性を指定するタグです。値は「r」(relaxed)と「s」(strict)の2つです。既定は「r」で、ドメインの部分一致を許容します。一方「s」では、ドメインの完全一致が必要です。
- fo失敗レポートの条件
- 失敗レポートのオプションは「0」「1」「d」「s」です。既定の「0」は、SPFとDKIMのアライメントがどちらもパスしない場合にのみ失敗レポートを生成します。「1」は、SPFかDKIMのどちらかがパス以外の結果になった場合に使います。「d」はDKIMの検証失敗、「s」はSPF関連の問題についてレポートを生成します。失敗レポートを実際に受け取るには、「ruf」タグの指定が必要です。
- rf失敗レポートの形式
- 失敗レポートの形式は「afrf」と「iodef」の2つから選べます。
- pct適用割合(旧仕様)
- 旧来の適用割合タグは、DMARCに失敗したメールの一部にだけquarantineやrejectを適用するよう受信側に求めるものでした。受信側の実装がばらついたため、RFC 9989でpctは廃止されました。新しいレコードでは省略し、集計レポート、ポリシー全体の変更、送信量の少ないサブドメインで段階的に移行します。
- riレポート間隔
- レポート間隔は、XMLレポートを受け取る頻度を秒単位で指定します。標準値は86400秒で、1日1回のレポートにあたります。ただし、指定した間隔にかかわらず、インターネットサービスプロバイダー(ISP)は通常、独自のスケジュールでレポートを送ります。多くの場合、それも1日1回です。
SPF
- v
- バージョンタグの値は「spf1」のみです。誤りや欠落があると、SPFレコードは無視されます。
- ip4
- そのドメインでメール送信を許可するIPv4アドレスを指定します。
- ip6
- そのドメインの名義でメール送信を許可するIPv6アドレスを指定します。
- a
- ドメインのIPアドレス(Aレコード)で送信元を検証します。指定がなければ現在のドメインが対象です。
- mx
- メールサーバーのMXレコードで送信元を検証します。指定がなければ現在のドメインが対象です。
- ptr
- 接続元IPのホスト名をPTRで照合します。DNSルックアップが多すぎるため、RFC 7208では非推奨です。
- exists
- 指定したドメインにAレコードが存在するかを確認します。
- include
- 正確なSPFレコードに欠かせないタグです。指定したドメインやサブドメインを、正規の送信元として受信側に示します。
- all
- SPFレコードの末尾に置くメカニズムです。限定子(~、+、-、?)で、記載のない送信元からのメールの扱いを受信側に示します。RFC 7208では必須ではなく、ない場合の結果はneutralです。
DKIM
- v
- 任意のタグです。指定する場合は値を「DKIM1」とし、レコードの先頭に置きます。
- p
- 公開鍵のタグです。DKIMの設定時に生成される文字列で、空のままでは有効になりません。
- t
- フラグをコロン区切りで列挙するタグです。定義済みのフラグは「y」と「s」で、未定義のフラグは無視されます。
- s
- レコードが対象とするサービスの種類を示すタグです。指定がない種類や不明な種類は、受信サーバーが無視します。
- h
- 許可するハッシュアルゴリズムを指定するタグで、既定ではすべて許可します。一覧は送信側が決め、受信側は不明なアルゴリズムを無視します。
- n
- 管理者向けの任意のメモ欄です。必要なときだけ使うことを推奨します。