皆さん、こんにちは。

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

さて、冒頭に書いたウェブサイトがジャックされた事件、今回はたまたま人気アニメシリーズの公式サイトであったものの、他でもあり得る話しです。

ウェブサイトがジャックされてしまった

この事件においてまず思い浮かんだこと、それは『脆弱性』です。

脆弱性をつかれてしまった場合、ウェブサイトが書き換えられてしまう可能性はあります。

しかし、今回は別の問題が起きているようです。

ウェブサイトというより、『ドメイン』がジャックされた感じを受けます。

この人気アニメシリーズの公式サイトに使われているドメインの情報を見てみると、2019年4月5日 01:18:00に最終のアップデートが行われており、『Registrant（登録者名）』がS社からU個人名に、『Name Server』もIからSに変更されており、『Contact Information（公開連絡窓口）』も変わってしまっています。

一説には、『人為的ミスにより、外部からのドメイン移管リクエストを承諾してしまったのでは？』という意見もありますが、そうでなかった悪意のある『ドメインジャック』であった場合には以下のことが考えらえます。

DNSサーバがジャックされ、DNSレコードを書き換えられてしまうなどによりドメインが不正に移管されてしまった。

これらのことへの対応策としては、

１．ドメイン管理に使用しているID・パスワードの適切な管理

２．WHOIS情報の定期的なチェック

３．DNSサーバが正しく設定されているかの確認

４．登録情報をロックして書き換えを防止する『レジストリロック』の導入

５．登録情報変更時などのメール通知サービスの活用

これらの備えが必要であると言えます。

皆さん、こんにちは。

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

昨今、DNS（Domain Name System）インフラを狙った攻撃が増加していることを受け、ICANN（Internet Corporation for Assigned Names and Numbers/アイキャン）が『DNSSEC（Domain Name System Security Extensions）』の導入を呼び掛けています。

では、『DNSSEC』を導入することで何が変わるのでしょうか？

DNSSEC導入で防げるリスク

このDNSインフラの改ざん被害、米国土安全保障省も全省庁に警戒と緊急対策を指示しているほど深刻な問題です。

ではDNS情報の改ざんは検知できないのか？

『DNSSEC』を導入すればそういった改ざんは検知できます。

『DNSSEC』はデータに対してデジタル署名を行うことで改ざんを防ぐ技術ですから、その導入が進めば多くのDNS情報の改ざんが検知できることになります。

（※　すべての攻撃を防げるわけではありません。）

つまり、リスクを減らすことができるわけです。

この『DNSSEC』、日本においてはさらに遅れた状態になっています。

『DNSSEC』はドメインのレジストラとホスト、両方がそれに対応している必要があり、一部のレジストラにおいては有償オプションとして対応しているものの、ホスト側においてはなかなか対応に踏み切っているところは少ない状態にあります。

また、ユーザー側の認知度も低い状態です。

それらを考えると日本における普及はまだまだ時間がかかりそうですが、少しでも多くのレジストラやホスティング会社の対応、そしてユーザーの利用が進むことを願うばかりです。

これにより、特定のドメイン名が名前解決できない現象が徐々に増えていく注意喚起が出ています。

皆さん、こんにちは。

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

さて、先週末の2019年2月1日にインターネットの世界ではDNSの回避策の機能を削除するということが起きています。

この機能削除の日を『DNS flag day』と言います。

今日はそれをお伝えします。

DNS flag day 以降の名前解決に問題が

まず、DNS（Domain name system）はインターネットにおいて重要なもので、これがないとウェブサイト（ホームページ）やメールの利用はできません。

そして、このDNSにはEDNS（Extension Mechanisms for DNS）という拡張機能があり、このEDNSの実装が正しくない、動作に不具合があるようなサーバなどに対しても名前解決ができるよう、回避策が実装されていました。

しかし、このような回避策を実装するという対応はDNSサーバの処理速度低下を招いたり、プログラムコードのメンテナンスや新規機能の実装を困難にさせたりする要因になっており、今回、それを改善するため、各種オープンソース実装をしている複数の組織が2019年2月1日以降にリリースされるDNSソフトウェアから『回避機能を取り除く』ことを発表したのです。

これによって何が起きるのか？

いくつかの現象が発生することが予想されていますが、その中の1つとして、正しくないEDNS実装のDNSサーバに対してEDNSを用いた通信ができなくなることにより、そのDNSサーバが提供するドメイン名に対して名前解決ができなくなる可能性がある。

つまり、ウェブサイト（ホームページ）の表示やメールの送受信が行えなくなることや、必要以上に遅延が発生する可能性があるということになります。

ただし、これは2019年2月1日（DNS flag day）を過ぎた時点で直ぐに何かが起きるわけではなく、新しいバージョンのDNSサーバの普及とともに徐々に増えていくとされています。

さて、この問題に対して自社や自店では何をすれば良いのか？

確認サイトが公開されていますので、自社や自店などのドメインを確認してみてください。

EDNS Compliance Tester

※　ドメイン名はwww.example.com等ではなく、example.comで確認してください。

その結果、『All OK』と出れば問題ありませんが、『The Following Tests Failed』と出てしまうようであれば問題があります。

その場合、契約しているサーバ会社などに確認をしてみると良いかもしれません。

皆さん、こんにちは。

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

いよいよ今年も残りわずかとなりました。

そこで、今年最後の投稿は今年の記事を総括していきます。

ITと情報セキュリティ

ITや情報セキュリティ関連に関しては以下のようなキーワードが浮かびます。

・CPU脆弱性問題（Meltdown（メルトダウン）とSpectre（スペクター））

メルトダウンとスペクター対応

・QRコードとキャッシュレス決済

新QRコードによる決済サービス

・Windows 7のサポート終了への準備

Windows7終了迄残り2年切る

・ビジネスメール詐欺（BEC）

ビジネスメール詐欺が国内にも

・ルータへの攻撃

ルータの設定変更攻撃が拡大中

・SMSによる宅配業者偽装

佐川急便を騙る偽SMSが急増中

・Windows 10 October Update 2018の配信停止

October 2018 Updateの問題

・Mozilla Thunderbird 64bit版登場

Thunderbird60系の64bit版

・Wi-Fiセキュリティの強化とVPN活用

Wi-Fiのセキュリティが強化へ

※　過去の記事へのリンクは一部のみ記載しています。

httpsとWebの高速化

Web関連に関しては以下のようなキーワードが浮かびます。

・Google Chrome、Mozilla Firefox の非HTTPSサイト（ページ）への警告

Chrome68は非HTTPSに警告

・WordPress 4.9.3でのアップデート不可バグ

WordPress4.9.3で嫌な不具合

・Webの高速化、高速パブリックDNS、PHP 7のススメ

ウェブの表示速度をさらに追求

・TLS1.0/1.1の終了

TLS1.0/1.1は順次対応を終了

・GDPR（EU一般データ保護規則）

GDPRの影響がドメインに出た

・WordPressのコメントスパム対策

WordPressのコメントスパム

・EC-CUBE 4の登場

EC-CUBE4系がリリースされる

※　過去の記事へのリンクは一部のみ記載しています。

会計・制度・法律

その他、会計、制度、法律関連に関しては以下のようなキーワードが浮かびます。

・2019年10月の消費税改正

消費税増税は中小8割が未着手

・IT導入補助金

IT導入補助金公募開始（H29）

・会社説明会の変化

新卒者向け会社説明会等に変化

・厚生年金パートへの適用拡大

厚生年金パートへ適用拡大検討

・働き方改革関連法

働き方改革関連法で変わること

・社保未加入の建設業者

社保未加入の建設業者は要注意

・有期契約労働者の無期転換申請

有期契約労働者の無期転換申請

・制作物の著作権

IT・WEB系の制作物での著作権

・GDPR（EU一般データ保護規則）

GDPRは国内向けも対象なのか

・特定電子メール法

特定電子メール法の誤った認識

※　過去の記事へのリンクは一部のみ記載しています。

他にも是非再読いただきたい記事はたくさんありますが、全体の中からピックアップして総括させていただきました。

最後に、今年もこのブログにお付き合いいただきましてありがとうございました。

たまに事業者向けなのか？という記事もなくはないですが、そこは従業員の方へ事業者からアナウンスしていただきたいという意味もあって投稿しております。

来年も事業者に役立つ記事の投稿を心がけて参りますので、どうぞよろしくお願い申し上げます。

年明けは2019年1月7日（月）から投稿を予定しております。

どうぞ良いお年をお迎えくださいませ。

皆さん、こんにちは。

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

昨日、米国のあるドメインレジストラ（指定事業者）からメールが届きました。

それによると、以前から延期となっていた『ルートゾーン情報の電子署名鍵（KSK：Key Signing Key）の更新（ロールオーバー）』が承認されたとなっています。

ICANNのロールオーバー承認による影響

今年の夏の時点では2018年10月11日の実施を予定していることにはなっていたものの、それはICANN（The Internet Corporation for Assigned Names and Numbers）理事会の承認待ちという状態でした。

しかし、レジストラからのメールによるとそれが最近承認されたとなっており、予定通り今月11日にKSKのロールオーバーが実施されることになります。

これによって影響を受けるのは、基本的には『DNSSEC（Domain Name System Security Extensions）』が有効になっているドメインに限りますが、以前の記事にも書いた通り、KSKロールオーバーによってDNS応答のパケットサイズが通常の倍以上になってしまった場合、ホスティング会社においてDNSキャッシュサーバへの対応がなされていなければDNSSECが有効になっていなくても影響を受ける可能性があります。

つまり、その場合は名前解決ができなくなり、ウェブサイトが閲覧できない状態になる可能性を秘めています。

行える対応策としては、

１．DNSSECが有効になっている場合、それを一度無効にする。それでも解決しない場合はISP（インターネットサービスプロバイダ）から新しい鍵を取得し、レジストラ側の更新を行う。

２．DNSSECが無効になっている場合、前述の通りホスティング会社のDNSキャッシュサーバへの対応によると思われますので、契約のホスティング会社に問い合わせてみることになります。

来週は自社（自店）運営サイトなどに注意です。

皆さん、こんにちは。

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

さて、『WordPress4.9.6でGDPR対応』という記事でも触れた通り、EU圏で始まった『GDPR』の影響はドメインにも及んでいます。

それは一体どういう意味なのでしょうか？

GDPRの影響がドメインにも出た

今回、ある海外のレジストラ（ドメインの登録・管理などを行う業者）が早々に手を打ってきました。

プライバシーを保護するための『Whois Guard』を永久に無料にすることを決めたのです。

ドメインは、登録者、管理者、技術担当者などの情報がデータベース化されており、これを保護する契約をしないと誰にでもそれらの情報が見れてしまいます。

そして、日本においてはドメインの新規登録時に同時申し込みをすることで無料になるキャンペーンを続けているところが多いようですが、海外の場合は基本的には常時オプション扱いで別料金が発生していました。

この、オプション扱いとなっている有料サービスは、GDPRによってプライバシーの保護が義務化されるため無条件で提供せざるを得ないということになります。

実はこの問題、既に『ICANN（Internet Corporation for Assigned Names and Numbers）』が『WHOIS』というデータベースに対して取り組みを続けているという報道が出ていました。

しかし、GDPRに違反した場合最大で2000万ユーロまたは年間売上高の4%のいずれか高い方を科される可能性があるため、早々に永久無料という措置を取ってきたのでしょう。

現に、GDPR施行直後に米国大手IT関連企業が既に提訴されてもいます。

これらのことを受け、今後はこのような動きが他でも出てくるのではないかと思われます。

皆さん、こんにちは。

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

さて、ネットワークやインターネット関連の携わっている方なら誰でも知っている『JPRS』ですが、ドメインの管理だけではなく、実はHTTPS化に必須なSSL（サーバー）証明書の発行サービスも行っています。

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

HTTPS化にJPRSのSSL証明書を使う

今やWebのHTTPS化は必須ともなってきており、それを行うにはSSL（サーバー）証明書が必要になります。

どうせHTTPS化を行うのに必要ならばイメージの良いところのものを使いたい。

しかし、できることならば安価なものがありがたい。

そんな事業者の方には『JPRS』のSSL（サーバー）証明書が良いかもしれません。

取り扱い事業者（指定事業者）を通じての購入になりますが、証明書の申請者が証明書に記載のドメイン名について登録者または管理者であることを証明する『ドメイン認証型』であれば、一番安い取り扱い事業者で972円/1年（税込）という安さでサイトシール（日本語、英語の2言語対応）もついています。

さらに、ルート証明書は『SECOM（セコムトラストシステムズ）』が運営しているため安心度も高いものになります。

HTTPS化に伴って高い信頼性などのイメージ的なアピールをされたい事業者の方には非常にお勧めなSSL（サーバー）証明書です。

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

皆さん、こんにちは。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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