皆さん、こんにちは。

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

さて、昨日に続きApple関連の情報です。

昨日、『iOS 12』にて『パフォーマンス改善』がされているというお話しをし、ある程度落ち着いたらバージョンアップをお勧めしました。

auにおいてはiPhone 5sがiOS 12へのアップデートでSMSの送受信ができなくなる（メッセージアプリでのMMS受信も）不具合も出ており、iOS 12へのアップデートを控える呼びかけがされています。

しかし、一方ではセキュリティ的なリスクも存在します。

Apple製品における脆弱性アップデート

iOSに限らず、他のApple製品に関しても脆弱性対応のアップデートがされており、以下のものが影響を受けるとされています。

・iOS 12 より前のバージョン

・Apple Support 2.4 for iOS より前のバージョン

・watchOS 5 より前のバージョン

・tvOS 12 より前のバージョン

・Safari 12 より前のバージョン

想定される影響として、

・情報漏えい

・アドレスバー偽装

・任意のコード実行

があげられています。

これらは既にアップデートが公開されていますので、Apple的には早期のアップデートをお勧めしますといったところでしょう。

iOS 12に限って言えば、iOS 12の正式リリースと同時に開発者向けのベータ版『iOS 12.1』が公開されており、早い段階でその正式版がリリースされる可能性が高いと思われます。

その際には、リリースが計画変更された『グループFaceTime（最大32人同時通話可能）』の機能も含めてリリースされるかもしれません。

皆さん、こんにちは。

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

6月に入り、またいくつかのフィッシングメール等が拡散されています。

今日はそれをご紹介します。

フィッシングメール等が複数発生中

ここ数日見受けられるものとしては以下のものがあります。

１．Appleをかたるフィッシングメール

２．VISA JAPANをかたるフィッシングメール

３．Amazonをかたるフィッシングメール

４．セゾンNetアンサーをかたるフィッシングメール

５．LINEをかたるフィッシングメール

６．佐川急便をかたるフィッシングメール

把握している限りでは上記のフィッシングメール等が出回っています。

１のAppleをかたるものに関しては、以前から出回っている『apple.com』を偽装したものが未だ残っている可能性があり、それに加えて『apple.co.jp』を偽装した『PDFファイル付』の『ポリシー』に関するもの。

２に関しては、VISAが問い合わせを受けたものの回答以外にメールを発信することはなく、本文を読んでも明らかに怪しい内容のもの。

３と４に関しては、偽サイトに誘導後、IDとパスワードなどを盗み出そうとするもの。

５に関しては、LINEの二段階パスワードを設置させると見せかけ、メールアドレスやパスワードを盗み出そうとするもの。

６に関しては、E-mailに加えてSMS（ショートメール）で送られてくるもの。

このようなものがあります。

昨今はスパム系のメールも巧妙化してきてはおりますが、これらのものは注意深く見れば必ずおかしな点が存在します。

また、リンクの張られたURLも表面的には正規のものが書かれていますが、中身を見ると全く異なるURLへのリンクが張られていることがわかります。

（絶対にクリックせず、マウスポインタをそのリンクURLにあわせてみるだけで確認できます。)

このようなメールは、少し注意を払えば被害を防ぐことができるものが大半ですので、常日頃からそういった習慣をもっておくことが重要です。

皆さん、こんにちは。

業務改善を行う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・業務コンサルタント、高橋です。

さて、皆さんもご存知の通り、送られてきたメールの差出人が『rakuten.co.jp』であったり、『apple.com』であったりし、件名や本文も本物にそっくりの状態で作られているために本物と勘違いしてしまう偽装メール。

こういったものを防ぐ手立てはないものでしょうか？

ドメイン偽装は防ぎようがないのか？

まず、ドメインを偽装するというのは簡単にできてしまいます。

そして、これを完全に防ぐことはできません。

そのため、大手企業はもちろんのこと、中小企業などにおいてもドメインの名前解決に用いられるDNSというものに対してそれなりのものが書かれていたりします。

それによって本物であることを認証させたりしているわけですが、正直なところ、メールを受け取る側においても意識をしない限り、実際のところは役に立たないことも多いです。

例えば、常日頃からIT系の業務に携わっている人であったりセキュリティ意識の高い人であれば、疑わしいメールが送られてきた瞬間にメールのヘッダ情報を確認したりします。

しかし、そうでない人はそこまでのことは行いませんし、ヘッダー情報を見てもわからないという人が大半です。

ではどうすれば良いのか？

１．業務上、メールのやりとりを行う相手先とは一定のルールを設ける

例えば、双方においてSPF認証は必須とし、メールサーバーにおいては認証していないものを隔離するか削除する措置を取るというのも1つの手でしょう。

２．社内においてマニュアルを作成し、全体に周知徹底を図る

３．一般の消費者に対して偽装メールが届いてしまった場合、ウェブ上で確認方法や注意喚起などのアナウンスを行う

ただし、３に関しては受信者からの問い合わせ連絡などがない限り大半の企業では把握していないことも多いかと思います。

それを早期に把握するため、DNSにDMARCというものを記述し、レポートが受け取れる状態にしておくことがお勧めです。

皆さん、こんにちは。

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

今日は業務の都合で少しだけ。

Appleから、iOSやmacOSに関する脆弱性対応のアップデートがリリースされています。

Apple製品の脆弱性対応アップデート

今回発表されているのは、以下のものに対する影響になります。

・Safari 11.1及びそれ以前のバージョン

・macOS hight Sierra 10.13.4（Security Update 2018-001 未適用）

・iOS 11.3.1より前のバージョン

想定されている影響は以下の可能性があるとされています。

・任意のコード実行

・権限昇格

・ユーザーインターフェースの偽装

対策方法は、ソフトウェアを最新のものにアップデートすることになります。

また、OS XやmacOS向けのSafari（11.1）の対策済みバージョンは以下の通りです。

・OS X El Capitan 10.11.6 向けの Safari: 11.1 (11605.1.33.1.4)

・macOS Sierra 10.12.6 向けの Safari: 11.1 (12605.1.33.1.4)

・macOS High Sierra 10.13.4 向けの Safari: 11.1 (13605.1.33.1.4)

早めのアップデートがお勧めです。

ご参考まで。

皆さん、こんにちは。

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

楽天、アマゾン、Yahoo!ショッピングなど、インターネット通販などで商品を購入する際に参考にされる口コミ、これ、実際は商品を購入していない人が書いている場合があったりします。

そういった口コミを装った自社商品のPRを行うことを『ステルスマーケティング』と言います。

では、実際にどのような形で行われているのでしょうか？

ステルスマーケティングの実態

ステルスマーケティングには2つのパターンがあります。

１．SNSなどでフォロワーの多い人材へ企業が報酬を支払って依頼する

２．企業内にて社員が第三者を装って投稿する

この2つのパターンです。

これらは本来、消費者を欺く行為であると思われますが、現時点においては法的な規制がないため放置されたままの状態です。

※　欧米においてステルスマーケティングは、消費者を欺く行為として禁止されています。

このような偽装は、発覚すればたちまち信用は失墜し、そのウェブサイトも閉鎖に追い込まれることすらあります。

※　実際に閉鎖に追い込まれたウェブサイトもあります。

立ち上げたばかりだから仕方がないとなどと思わず、着実に間違いのないことを行っていくことが一番です。

皆さん、こんにちは。

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

以前から結構拡散されていた『楽天カード』を騙るスパムメールですが、ここ最近はより偽装が巧妙になってきました。

今日はそれに関してお伝えします。

楽天カードを騙るHTML形式のウイルスメール

以前拡散されていたものはテキスト形式のシンプルなものでしたが、ここ最近はHTML形式になり、かなり本物に類似した見た目になっています。

また、送信元のメールアドレスも、本来の楽天カードの正規ドメインである『mail.rakuten-card.co.jp』に偽装されているため、表面上は見分けがつきにくいものにもなっています。

この件に関して警視庁サイバー犯罪対策課は、以下のように注意喚起をしています。

ウイルスをダウンロードさせるメールが拡散中。件名は『カード利用のお知らせ』。実在の会社を装っていますが、本文中のリンクをクリックしてダウンロードされるファイルはウイルスです。ご注意ください。

― 警視庁サイバーセキュリティ対策本部 (@MPD_cybersec) 2017年12月14日

メールの件名は『カード利用のお知らせ』や、『【重要】カスタマーセンターからのご案内【楽天カード株式会社】』などとなっており、本文中に記載のリンクをクリックするとウイルスをダウンロードする仕組みとなっています。

いつもの通り、身に覚えのない内容のメールに記載のリンクはクリックせず、不明な添付ファイルも開かないよう、ご注意ください。

皆さん、こんにちは。

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

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

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

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

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

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

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

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

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

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

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

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

皆さん、こんにちは。

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

以前に一度DNSSECに関して触れたことがあります。

DNSSECを使えるなら使うべきという記事にて触れさせていただきました。

これをおさらいしておくと下記のようなことを行っています。

DNS応答の完全性検証

ドメインは、DNSというものにて名前の解決を行っています。

簡単には、住所のようなIPアドレスとドメインの紐づけを行っているようなものなのですが、そのDNSの応答は答えが正しいものかどうかのチェックを行っていません。

それにより、偽装された応答を紛れ込ませておいて偽サイトのサーバーへ誘導させてしまうことも起きています。

それを防ぐためにDNSSECというものを使い、ユーザーがWEBサイトを訪れようとした際に行われるDNS応答が正しいものであるかを鍵と署名をつけて返し、それらから守ったりします。

DNSSECの署名キー作成と設定

しかし、DNSSECというものでDNSを保護できることを知ったとしても、その作成から設定に至るまでの手順があまり知られていないように感じます。

そこでDNSSECの作成・設定手順を記載しておきます。

１．ウェブサイトを置いているホスティング会社にDNSSECの署名キー作成・発行依頼をします。

　　（例：お名前.comのサーバーを使っているのであればお名前.comへ依頼）

２．example.jp. 86400 IN DS 60485 5 1 (2BB183AF5F225…)といった感じのものが発行されます。　

３．２の内容をドメインを管理している指定事業者（お名前.comのようなところ）へ登録します。

基本的にはこの手順でDNSSECの設定は完了します。

ただし、１と３のそれぞれにおいてDNSSECの対応をしていることが前提になりますので、対応の可否は契約先に確認してみてください。

追伸：アルゴリズム番号は”8″か”10″（海外のように”13″の対応がまだなので）、ハッシュは”SHA-256″をお勧めします。