皆さん、こんにちは。

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

米AnchorFreeが提供する『Hotspot Shield』というVPN（仮想プライベートネットワーク）ソフト、日本ではソースネクストも『Wi-Fiセキュリティプレミアム』として日本向けにローカライズされたものを販売していますが、これに含まれている一部のプログラム、妙な動きをすることがあります。

Hotspot Shieldにおける妙な挙動

この『Hotspot Shield』というVPNソフトは、インストール後にアプリケーションを常駐させていなかったとしてもバックグラウンドでサービスが自動起動しています。

また、サービスの一覧を見てもわからない、『hydra.exe』というものが妙な挙動をすることがあります。

何をしているか詳細はわからないのですが、何らかの通信を行っています。

そして、それを検知したセキュリティソフトがアクセスをブロックしようとします。

これに関係しているのが『hydra.exe』というプログラムです。

このプログラム、通信におけるポートの使用などから25%程度の危険性は認められるものの、署名自体は米AnchorFreeが正式に署名したものではあります。

実際のところ、このプログラムはなくてもVPNとしては使用できますので、削除してしまっても良いでしょう。

場所は、『C:\Program Files (x86)\Hotspot Shield\bin\』の中に入っています。

ただし、この『hydra.exe』が『C:\Windows』または『C:\Windows\System32』に存在する場合はマルウェアウイルスの可能性がありますので、セキュリティチェックを行い、有害なものであれば駆除する必要があります。

皆さん、こんにちは。

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

今年の夏から来年の春にかけ、ICANN（The Internet Corporation for Assigned Names and Numbers）がルートゾーンに重要な更新を実施するようです。

さて、重要な更新とはいったい何が起きるのでしょうか？

KSKロールオーバーが行われる

以前、『DNSSECを使えるなら使うべき』という記事などにおいて『DNSSEC』というものに関して触れましたが、このDNSSECにおいてDNS応答の検証に使われるルートゾーン情報の電子署名鍵（KSK：Key Signing Key）が更新（ロールオーバー）される、これが今回行われる重要な更新ということです。

DNSのルートゾーンには、ルートゾーンのレコードに署名するZSK（Zone Signing Key）と、そのZSKに署名するKSKとがあり、ZSKは3ヶ月に一度更新されるようですが、KSKは今まで一度も更新されたことがなく、今回初めて更新されることになります。

（本来は5年に一度更新されることになっているようですが、今回は初めての更新のため、2年間の準備期間を設けていたようです。）

では、これによってどのような影響があるのでしょうか？

DNSSEC未使用でも影響を受ける

KSKロールオーバーによる影響は、前述のDNSSECを使っていなければ問題ないというわけではなく、DNSSECを使っていなくても影響を受ける可能性はあるようです。

これは、KSKロールオーバーによってDNS応答のパケットサイズが通常の倍以上になってしまう可能性があり、それによって名前解決ができなくなる、つまり、DNSSECの有無にかかわらず影響を受ける可能性があるということです。

名前解決ができなくなった場合はどうなるか？

当然、ウェブサイトは閲覧できない状態になります。

ただし、実際に影響を受けるのはDNSキャッシュサーバの運用者などになりますので、ホスティングでウェブサイトを公開しているだけの一般ユーザーは基本的には影響はないようですが、ホスティング会社なども現在対応を協議中としているところもあり、その対応がなされれば問題は発生しないということにはなります。

ご参考までに。

※　CDNとは、Webコンテンツをインターネット経由で配信するために最適化されたネットワークのことです。

皆さん、こんにちは。

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

CDNサービスの中でも無料プランが用意されていることで有名なCloudflareですが、この無料の範囲には注意しなければいけないものもあります。

※　無料プラン以外に、プロプラン（$20/月）、ビジネスプラン（$200/月）、エンタープライズプラン（$5,000/月）があります。

Cloudflareの仕組み

CloudflareなどのCDNは、レンタルサーバなどのオリジナルサーバとVisitorであるウェブサイトへの訪問者（ブラウザ）の間に存在します。

オリジナルサーバにあるコンテンツをCloudflareなどのCDNサービスが最適化（キャッシュや軽量化など）を行い、ウェブサイトへの訪問者に提供しています。

もちろん、ウェブサイトへの訪問者はそういったサービスが介在しているウェブサイトかどうかはわかりません。

通常のウェブサイトと全く同じように閲覧することになります。

CloudflareにおけるSSLの注意点

CloudflareのSSL（暗号化通信）には、Off、Flexible、Full、Full（strict）の選択があり、Offはもちろん暗号化通信なしですが、Flexibleはウェブサイトへの訪問者とCloudflareの間のみ暗号化通信され、Cloudflareとオリジナルサーバの間は暗号化通信されません。

また、FullのモードにおいてはCloudflareとオリジナルサーバ間においても暗号化通信がなされますが、Fullの場合はオリジナルサーバ側のSSL証明書が自作のものであってもよく、Full（strict）の場合のみ公的に信頼された認証局によって署名された有効なSSL証明書を要するというモードになっています。

つまり、完全な暗号化通信と公的に信頼された認証局に署名されたSSL証明書、これらの条件が必ず満たされていなければならないのはFull（strict）のモードのみということになります。

一般的に考えた場合、ウェブサイトの常時SSL化は訪問者のブラウザとオリジナルサーバの間が暗号化通信となり、そこには公的に信頼された認証局に署名されたSSL証明書が存在します。

ここから考えると、こういったCDNサービスを使う場合においてもすべてに暗号化通信がなされ、公的に信頼された認証局に署名されたSSL証明書が存在することがユーザーの安全性を確保するものと考えることが妥当でしょう。

そのあたりは是非念頭において活用していただきたいものです。

ちなみに、Full（strict）のモードはビジネスプラン、エンタープライズプランへのアップグレードや、Cloudflareにおける専用証明書の購入をしなくても使うことは可能ですが、ブラウザにてSSL証明書の発行先確認をした場合にはCloudflareのドメイン（Universal SSL）が表示されるため、訪問者に安心してもらうにはサイトシールなどにてドメインや企業名などの確認ができる状態を作っておくことが望ましいと思われます。

皆さん、こんにちは。

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

以前に一度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″をお勧めします。