皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いたAppleの対応は既に『Yahoo!』や『AOL』などでも行われており、今後はさらなる厳格化が行われていくものと思われます。

では、これによってどのようなことが起きるのでしょうか？

Appleも行ったDMARCポリシーの変更

DMARCについては以前にもこのブログで書いたかもしれませんが、簡単に言えば『なりすましメール』を防ぐためのもので、『SPF』、『DKIM』、どちらの認証にも失敗した場合に受信サーバにはどのようにして欲しいかを記述したものになります。

これを、Appleは昨年の7月に『none（規定しない）』から『quarantine（未認証メールは受信サーバで隔離）』にレベルを引き上げました。

つまり、送信元が『@mac.com』、『@me.com』、『@icloud.com』などのAppleが提供しているメールは認証されたAppleのサーバから送信されない限り迷惑メールフォルダに入ることになります。

ただし条件があります。

受信する側のサーバがDMARCポリシーの処理に対応していることが必要です。

これらのDMARCポリシーに対する厳格化の動きは他でも進んでおり、『Yahoo!』や『AOL』などにおいては『quarantine』よりもさらに厳格な『reject（未認証メールは完全に拒否し受信しない）』に移行したとされています。

おそらくAppleも段階を経てDMARCポリシーを『reject』にしていくことでしょう。

『Gmail』や『Microsoft』もDMARCポリシーを『reject』に変更するとされています。

（確認したところMicrosoftは実施済みでした。）

そして、これらの動きに他のサービスプロバイダも追随してくれることでさらに『なりすましメール』を防ぐいくことができるでしょう。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今朝、トレンドマイクロ社のあるコラムを読んでいたところ、『ビジネスメール詐欺』に関連したものが紹介されていましたので、今日はそれをお伝えします。

類似ドメインを使ったなりすまし詐欺

事業者の場合、メールを送信する際に『なりすまし』対策の一つとして『SPF（送信元メールサーバのIPアドレス確認）』、『DKIM（電子署名確認）』、『DMARC（SPFとDKIMの認証を利用した認証と処理宣言）』といったドメイン認証を用いていることが多いですが、それを逆手に取ったような事象が起きています。

それは、『類似ドメイン』を使った『なりすまし』詐欺です。

例えば、example.comというドメインがあったとします。

この『example.com』になりすましたい場合、偽物のドメインとして『exarnple.com』というドメインを使い、事業者へ『請求書』などのメールを送りつけます。

この例によるポイントは、exampleの『m（エム）』を『rn（アール・エヌ）』に変えて模倣されている、『模倣ドメイン』であることです。

確かに、パッと見た限りでは『rn（アール・エヌ）』が『m（エム）』に見えてしまいます。

そして、この模倣ドメインと『SPF』、『DKIM』、『DMARC』といったドメイン認証を組み合わせることで余計に本物であるかのように見えてしまいます。

理由は簡単です。

模倣ドメインは攻撃者側が所有しているドメインですから、『SPF』、『DKIM』、『DMARC』、いずれも正常に認証をPassさせることができるからです。

『m（エム）』と『rn（アール・エヌ）』以外にも、『0（ゼロ）』と『O（オー）』、『o（オー）』と『a（エイ）』、『S（エス）』と『5（ゴ）』などがだましの模倣ドメインに使われていたりします。

このような『なりすまし』に対しては、徹底した社内教育に加え、それらを検知するセキュリティの導入などにてリスクを軽減する必要があるとされています。

参考：『ビジネスメール詐欺：DMARCなどドメイン認証のすり抜けを狙った手口』

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた内容はある企業にて施されているメール送信に対する施策ですが（SPF、DKIM、DMARC）、この状態でも偽装されたメールは受信者に届いてしまうことはあります。

それは何故でしょうか？

DMARCの宣言が絶対ではない理由

まず、DMARCにはポリシーというものがあり、どのように対処通知を行うかの記述があります。

１．何もしない（none）

２．隔離（quarantine）

３．拒否（reject）

これにプラスして、どれくらいの割合でメールを評価するかの適用割合というものが記述されている場合もあります。

従って、DMARCによる宣言があるからと言って必ず偽装されたメールが受信者に届かないわけではありません。

（ポリシーの設定を『何もしない（none）』にしているケースはよくあります。）

また、DMARCにおいて『拒否（reject）』としている場合でも受信者に届くことはあります。

それは何故か？

受信者側のメールサーバーに委ねている部分があるからです。

DMARCは受信者側に対して通知（要求依頼）はするものの、それに対応する形で受信者側のメールサーバーが設定されていない場合はその通知は適用されません。

（適用しようがありません。）

これらのことを理由に、DMARCによる宣言があるからと言って偽装メールが絶対に届かないようになっているというわけではないのです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今日の記事ですが、中小・零細企業、小規模事業者において『DKIM』まで導入することは難しい（レンタルサーバが対応していない場合が多い）などの理由から、それが行えない前提として読んでください。

『DKIM』導入可能な場合においては下記の限りではありません。

さて、自社や自店のドメインが偽装されたメールなどに使われていたことを知っても、ある意味では八方塞がりになってしまう可能性があります。

それはどういった状態だと思いますか？

DMARCのポリシーは受信者の協力も必要

事業者が使っているドメインであれば、DNSのTXTレコードにSPF認証に関する記述が加えられていることは昨今においては普通のことと言えます。

逆に、記述がないのであれば追加しておくべきです。

例：example.com. IN TXT “v=spf1 ip4:***.***.***.*** include:example.com -all”

（***.***.***.***の部分はv4のIPアドレスが入ります。）

さて、このSPFに関する記述が入っている場合でDMARCの記述も追加されている場合、Appleなどはポシリーを『none（指定なし）』にしていますが、MicrosoftやGoogleは『reject（拒否）』にしています。

これ、受信者が転送処理などを行わずにストレートにメールを受信している場合においては『none（指定なし）』から『quarantine（隔離）』、『quarantine（隔離）』から『reject（拒否）』と、フィルター処理の割合を組み合わせながら段階的にポリシー変更を行っていけば良いですが、受信者が転送処理などを行っている場合、相手のサーバ設定によっては『none（指定なし）』から他に変更することで問題が生じます。

例えば、受信者が自動転送設定をしていた場合で、その際のIPアドレスの出力を転送元IPアドレスとしていた場合、送信元ドメインとそのIPアドレスが一致せず、SPF認証は『Pass』とならないため受信者がメールを受け取れない可能性が出てきます。

（DMARCのフィルター処理（PCT）の設定値にもよります。）

このような場合においては正直八方塞がりのような状態になります。

従って、受信者側に自動転送をやめてもらうか、受信者側に転送先メールアドレスを開示いただくか、何らかの協力をお願いすることになります。

（メールサーバの仕様を簡単に変更するわけにもいきませんので。）

まずは偽装されたメールが出回っていることをアナウンスすることからスタートですが、『全く関係のない消費者などが被害にあわない』、『自社や自店のドメインを傷つけない』ためには、最終的にはDMARCのポリシーを『reject（拒否）』にできる環境整備を行っていく必要性があるでしょう。

また、冒頭でも書きました通り、これを送信者側のみで解決しようとした場合は『DKIM』の導入が必要となります。

しかし、それはロシアから送られてきたレポートでした。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

私は普段、偽装メール（なりすまし）対策の一環としてSPFやDKIM、DMARCを使うことをお勧めしていますが、この偽装メール（なりすまし）は日本国内に限った話しではありません。

ロシアから届いたDMARCレポート

普段、DMARCレポートが届くのは現状Googleからのみであったのですが、ある日、ロシアからDMARCレポートが届きました。

その段階では、このロシアからのDMARCレポートそのものがスパムメールなのでは？と疑いをもち、メールのヘッダ情報などを調査しましたが問題は見受けられませんでした。

何かしっくりこず、セキュリティチェックを通してレポートファイルを確認したところ、どうやらロシアのIPアドレス宛にコーポレートドメインを偽装してメールが配信されたようでした。

前者の方はロシアでメールを含めたサービスを提供している企業で、その企業がDMARCレポートを配信する仕組みを取り入れていたことからコーポレートドメインのDMARCレポートが届いたということで、実際に問題な行為を行ったのは後者のIPアドレスを利用した者と考えられます。

このように、偽装メール（なりすまし）は日本国内宛にとどまらず海外宛にまで及んでいます。

現在、コーポレートドメインをはじめすべてのドメインに対してDMARCを採用しているのですが、メールに対する制御は『none：そのまま受信させる』のまま様子見をしていた状態でした。

今回のことを考えると、やはり『quarantine：隔離させる』か、『reject：受信を拒否する』に変更していくことになるでしょう。

これらに変更することで、受信者のメールサーバーに対して隔離、もしくは拒否を依頼することができますので被害を抑制することが可能です。

しかし、課題も残ります。

先日起きたケースとして、相手先がGmailなどに自動転送していた場合、Fromは送信元メールアドレスのままなであったものの、出力されるIPアドレスは転送元のIPアドレスでした。

（相手先の契約サーバーの仕様によって左右されます。）

このような場合はつじつまがあわないことになりますのでSPF認証は失敗となり、DMARCにおけるメールの制御によっては相手にメールが届かないケースが出てきたりします。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

やはりGWは要注意です。

今朝のインターネットニュースなどを見ると、『Apple Store』の偽メールの記事を見かけましたが、私が体験したのはそれではありません。

『あなたのApple IDのセキュリティ質問を再設定してください』という、Apple IDに関する偽メールでした。

GW終盤を襲った膨大なスパムメール

GW終盤の5月5日、16時半前後にiPhoneでメールをチェックした時、膨大な『Apple』からの偽メールを受信したことが始まりです。

その時点で受信した数は70通ほど。

やむを得ずメールサーバーの設定を変更することに。。。

確認すると、スパムメールの始まりは15時半過ぎくらい。

内容は、以下のようなものです。

From：Apple<noreply@email.apple.com>

件名：あなたのApple IDのセキュリティ質問を再設定してください。

本文：お客様のApple IDが、ウェブブラウザからiCloudへのサインインに使用されました。

日付と時間：2018年5月5日 **:** JST

のブラウザ：Mozilla Firefox

オペレーティングシステム：Windows

IP：***.***.***.***（静岡）

上記が問題でない場合は、このメールを無視してください。

あなたのアカウントの安全性を守るために、セキュリティ質問を再設定して頂くことが必要です。再設定された後、たとえあなたのApple IDとパスワード及び元のセキュリティ情報を知っているとしても、それを使用することができません。

この問題を解決するにはこちら

今後ともよろしくお願い致します。

Apple サポートセンター

Apple ID | サポート | プライバシーポリシー
Copyright 2018
Apple Distribution International, Hollyhill Industrial Estate, Hollyhill, Cork, Ireland.
すべての権利を保有しております。

こういった内容です。

※　すべての本文は確認していませんので、これとは異なる内容のものもあるかもしれません。

これ、メールサーバーのフィルタリング設定を変更している最中にも次々に届き、この日だけで300通くらいは届いていたかと思います。

Appleを装ったスパムメール対策

このようなスパムメールが届く場合、サーバー側でフィルタリング設定が可能なのであれば以下のような設定をすると良いです。

『ヘッダ全体（全体）』に『apple.com』を『含む』かつ

『ヘッダ全体（全体）』に『SPF: pass』を『含まない』かつ

『ヘッダ全体（全体）』に『***.***.***.***（実際にはAppleのIPアドレス）』を『含まない』

すべてのメールを『削除』

これは1つの例で、私の場合は、SPF認証もpassせず、IPアドレスも把握しているAppleのものではないのであれば、まずスパムであると判断して間違いないという考えからこのようにしています。

また、IPアドレスの部分は勝手に公表すべきではないと考えましたので、過去に受信した正規のAppleからのメールのヘッダ情報を確認し、そのIPアドレスをチェッカーなどで確認してみてください。

Appleは膨大なIPアドレスを持っていますが、私が確認した限りでは、日本のユーザーに配信されるIPアドレスはある程度特定できます。

そして、一部異なる部分はワイルドカードで指定してあげれば正規のAppleからのメールのみを受信できるかと思います。

これが少々怖いという場合、フィルタリングに問題がないことを確認するまでの間はどこかに隔離するなどし、一応確認だけは行えるようにしておくのも良いでしょう。

最後に、長期休暇中はこのようなスパムメールが多発することが多いです。

連休明けに受信したスパムメールに騙されないように注意してください。

間違ってもリンク部分をクリックしないように。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

頻繁に送られてくる『楽天市場』を装ったスパムメールですが、昨日と今日に渡り、執拗なまでに拡散しているように思われます。

楽天市場を装ったフィッシングメール

現時点においては、4月24日（火）、25日（水）と、連日に渡って何通もの『楽天市場』を装ったスパムメールが拡散しています。

このメール、パッと見た限りではわかりにくく、本文中に張られたリンク先をクリックさせるフィッシングメールと思われます。

件名：【楽天市場】注文内容ご確認（自動配信メール）

差出人：楽天市場

本文：本当の楽天市場から送られてくる自動配信メールに酷似したHTML形式のもので、ショップ名は複数あるため固定ではありません。

ただし、購入したことにされている商品が、3万数千円程度（34,800円であったり、38,800円であったり）の『40V型LEDフルハイビジョン液晶テレビ（微妙に書き方が違う場合あり）』であることは共通しているように見受けられます。

メールのヘッダー情報を見ると、SPF認証には成功していない『Received-SPF: softfail』、IPアドレスは本当の楽天市場では使われていない海外（ロシアやブルガリアあたり）のIPアドレスが多く見受けられます。

このスパムメールは添付ファイルもありませんので、リンクをクリックしなければ何も問題は起きません。

また、受け取ることすら拒否したい場合、メールサーバにてフィルタリングすることで対応は可能です。

ただし、送信元のドメインを拒否してしまうと本当の『楽天市場』からのメールがすべて届かなくなってしまいますので、『SPF: pass』を『含まない』や、IPアドレスを交えた条件を指定する必要があります。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

日々さまざまな迷惑メールが拡散されていますが、今回は『佐川急便』を装った迷惑メールが事業者宛に送られているようです。

佐川急便を装ったメールで感染の恐れ

今回のものは事業者宛に送信されているようで、迷惑メールに記載されているアドレス（URL）にアクセスするとウイルス感染する可能性があるとされています。

件名は『[佐川急便]請求内容確定のご案内』とされており、電子請求書発行サポートに登録したユーザーを対象に配信したとされるものです。

本文中には『請求書番号』、『WEBトータルサポート（電子請求書発行サポート）へのログインはこちら』などに誘導用のリンクが施されており、それらのアドレス（URL）からアクセスしてしまうことでウイルス感染してしまう可能性がありそうです。

ちなみに、この迷惑メールは実際に私の会社にも届きましたが、佐川急便にメール登録しているかどうかは無関係のようです。

また、ドメインから考えると事業者宛に送られていることも理解ができますが、メールアカウントから考えると事業者宛ということが当てはまらない可能性もあります。

送信元はブルガリアからのようですが、こういった迷惑メールは海外から複数のサーバーを経由して送られてくることと、今回は経路偽装はありませんでしたが、それが偽装されていることも普通にあります。

ただ、SPFを見るとfailであることから佐川急便のドメインを偽装していることは明らかです。

これらの迷惑メールは日々さまざまな形で拡散されており、残念ながら根絶することは不可能です。

セキュリティソフトによる検知と、メールに対する注意を常日頃から心掛けることが重要です。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

2010年以降減少傾向にあった迷惑メールの検知数は、2016年に入って再び上昇し、増加しています。

そして、中でも多いのは『なりすましメール』と呼ばれるものです。

この『なりすましメール』を排除していくには、メールの送信側と受信側における連携が必要であり、送信側においては送信するメールの正しい情報を提供することが必要になります。

送信ドメイン認証の仕組み

前述の通り、まずは送信側において正しい情報を提供する必要があります。

その第一歩として送信ドメイン認証を使ったりしますが、その場合には下記のような状態となります。

※前提：送信側・受信側ともにSPFを導入済み

１．送信側のA社が受信側B社にメールを送ります

２．受信者側のB社はA社のDNSサーバに問い合わせを行います

３．２の要求に対し、A社のDNSサーバが送信用メールサーバに関する情報を返します

４．３の確認結果に基づきメールを配信する

SPFレコードの設定方法

送信側の設定としてはDNSサーバにSPFレコードを追加します。

そこに、SPFもしくはTXTとして以下の記述を追加します。

※前提：送信用メールサーバのIPアドレスが192.1.1.1の場合で、ドメインがexample.comの場合

“v=spf1 +ip4:192.1.1.1 -all”

これを追加するだけです。

また、受信側としてSPFの検証機能を導入すれば『なりすましメール』を区別できるようになりますが、メールサービスやメールサーバソフトによって異なりますので、ご利用のレンタルサーバ会社へ問い合わせることなどが必要です。

（レンタルサーバ側にて導入済みであれば、受信側としては何も行うことはありません。）

ただし、昨今SPFだけでは不十分ということも指摘されており、近いうちにそれを補うものをご紹介できればと思います。