その『ポップアップ』、CDN（Content Delivery Network / コンテンツデリバリネットワーク）を悪用した『ウイルス』かもしれません。

皆さん、こんにちは。

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

今朝、インターネットニュースで紹介されていた、あるアパレルのECサイトを訪れた際にセキュリティがアクセスをブロックし、脅威を削除しました。

これ、CDN（Content Delivery Network / コンテンツデリバリネットワーク）を悪用したウイルスです。

Cloudfront.net には要注意

さて、冒頭に書いたような『ポップアップ』が突然現れる現象についてですが、今回のものは『Amazon』の『CDN（Content Delivery Network / コンテンツデリバリネットワーク）』を悪用した『Cloudfront.net ポップアップ』であると思われます。

幸いにもセキュリティソフトがアクセスをブロックしてくれたため問題は起きませんでした。

この手のものの場合、広告を表示する『アドウェアウイルス』に感染している場合があります。

今朝セキュリティソフトがブロックしたものは残念ながら『トロイの木馬』でした。

このような場合、セキュリティソフトによってアクセスがブロックされたとは言え、やはり念のためにコンピュータの『ウイルススキャン』を実施しておくべきです。

（ブラウザのキャッシュ削除もお忘れなく。）

私も朝からすべてのドライブに対して『ウイルススキャン』を実施しました。

結果的にはアクセスがブロックされていたことでコンピュータへの感染はありませんでしたが、このような場合には念には念を入れておく必要があります。

今回私が訪問したウェブサイトに関してはカテゴリーレベルでしかお伝えできませんが、こういったケースはどこにでも存在すると言っても過言ではありません。

常日頃からセキュリティソフトを使って『Webアクセス保護』も行い、何らかの脅威がブロックや削除がされた場合には『コンピュータ』、『つながっているドライブ』などの『ウイルススキャン』を実施されることで安全を確保する意識が重要です。

皆さん、こんにちは。

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

さて、気にされている方は一部かもしれませんが、昨今のGoogleの考え方を考慮し、ウェブサイトのパフォーマンスを気にされる方は少なからずいらっしゃいます。

しかし、『どれだけ頑張っても同業他社に勝てない！』といったことは普通にあります。

では、これらをどのように捉えたら良いのでしょうか？

同業他社とのパフォーマンス比較

まず、同業他社とパフォーマンス比較をした場合、それは前提条件が違っているはずです。

自社はA社のホスティングサービスを使い、比較している相手はB社のホスティングサービスを使っている。

A社とB社のハードウェア構成、バックボーン、ハードウェア上に搭載されているOSやPHPなどのプラットフォーム仕様、これらはそれぞれホスティングサービス会社によって異なります。

その状態で比較しても勝てないのは当り前でもあります。

それよりも、自社のウェブサイトはどれくらいのパフォーマンスが出ているのか？

それはユーザーが不満に思うほどのものなのか？によります。

そのような状態にないのであればパフォーマンスにそこまで執着する必要はないとも言えます。

ある一定レベルのパフォーマンスを保持できているのであれば負けている理由はやはり中身の問題です。

どれだけユーザーが必要としている良質な最新の情報を提供できているか？が一番重要で、パフォーマンスはその後の問題になります。

昨今のホスティングサービス会社の仕様を見る限り、よほど名の知れぬ会社のサービスを利用していない限りはそれなりのパフォーマンスは出るはずです。

今一度自社の提供している情報を同業他社と比較してみることがお勧めです。

皆さん、こんにちは。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

では、PHP7.2系以前のバージョンと比較してパフォーマンスなどはどう改善されたのでしょうか？

皆さん、こんにちは。

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

過去に、『PHPを使う際のレンタルサーバ』、『PHP7.1でパフォーマンス向上』、『PHP7.2系のパフォーマンス他』という記事にて、PHPのパフォーマンスの改善をご紹介してきました。

では、現在の最新系であるPHP7.3系はどれほどの改善がなされたのでしょうか？

PHP7.3系のパフォーマンス改善など

さて、PHP7.3系（現在の最新バージョンは7.3.3）はPHP7.2系（現在の最新バージョンは7.2.16）と比べてどれくらいパフォーマンス改善がなされたのか？

前回、PHP7.2系がPHP7.1系と比べて『約10%程度の改善』であったということを書きましたが、今回も『約10%程度の改善』といった感じのようです。

私はベンチマークテストを行ってはいませんが、他の方のテストによるとPHP7.2系よりPHP7.3系は『約10%程度高速』に動作したようです。

私が試したのはパフォーマンスのスコアテストですが、確かにスコアはアップし、体感的にもごくわずかに高速になったように感じられます。

パフォーマンス以外では、WordPress5.1.1（現在の最新バージョン）においてデバッグモードでの動作テスト上、PHP7.2系で出ていた非推奨の警告に変化は見られませんでした。

その他、PHP7.3系にて非推奨となった機能は、

・Case-Insensitive Constants

・Namespaced assert()

・Searching Strings for non-string Needle

・Strip-Tags Streaming

・Data Filtering

・Image Processing and GD

・Internationalization Functions

・Multibyte String

・ODBC and DB2 Functions (PDO_ODBC)

というように掲載されています。

結論として、パフォーマンスに関しては PHP7.3.x ≧ PHP7.2.x で、WordPressの最新推奨環境も PHP7.3 以上となっていることもあり、『PHP7.3系』がお勧めです。

皆さん、こんにちは。

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

皆さん、『1Gbps』と書かれているのと『1GBps』と書かれているのでは違いがあることをご存知でしょうか？

これはよくありがちな認識違いですが、今日はこの少々雑談的なことをお伝えします。

bpsとBpsは単位が違う

『bps』と『Bps』をパッと見た限りでは『b』と『B』、小文字か大文字の違いしかないので同じものだと思っている方も多いかもしれません。

しかし、これはちゃんと単位が違うものの表記です。

『bps』は『bits per second』、1秒間に何ビット転送できるかになり、『Bps（B/s）』は『Byte per second）』、1秒間に何バイト転送できるかを表しています。

また、『bits』と『Byte』は『8bits』＝『1Byte』、つまり『bps』の表記があった場合にそれを『Bps（B/s）』に変換すると8分の1になります。

例えば、光ファイバー回線業者のウェブサイトを見ると『1Gbps』という表記がありますが、これを変換すると『0.125GBps（125MBps）』ということです。

（※　十進法表記と二進法表記では異なりますので、『0.128GBps（128MBps）』という変換表示になることもあります。）

逆に、パソコンでデータを異なるハードディスクに転送しようとした場合、『1GB/秒（1GBps）』と表示されたりしますが、これをビットに変換すると8倍の『8Gbps』ということになります。

『ビット』と『バイト』の違い、ご理解いただけましたでしょうか？

ご参考までに。

さて、この『Password Checkup』とは？

皆さん、こんにちは。

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

日本国内においてもウェブブラウザのシェアが半数を超える『Google Chrome』ですが、今回、スタンフォード大学の協力を得て『Password Checkup』というものを開発しました。

では、『Password Checkup』とは？

Password Checkupで漏えいチェック

さて、『Google Chrome』の拡張機能として登場した『Password Checkup』とは、名前の通りパスワードをチェックしてくれるものです。

Chromeブラウザでアクセスしているサイトへのログイン情報が第三者に漏えいしていないかをチェックしてくれ、入力したIDとパスワードが流出データと一致していれば警告を発するようになっています。

元々、Googleアカウントに限ってはパスワードの漏えいや悪用を検知するとパスワードが自動的にリセットされる仕組みになっており、その仕組みの効果もあってリスクは通常の1/10程度にまで抑えられているとされています。

今回リリースされた『Password Checkup』はこのGoogleアカウントの保護機能の仕組みを応用し、他のサイトにおけるログイン情報の漏えいなどを検知できるようにしたものです。

ログイン情報が流出したアカウントは40億以上もあるとされており、そういったアカウントの流出は自身ではなかなか気づかないものです。

そのため、今回リリースされた『Password Checkup』などを使うことで警告が発せられた時点で即座にパスワード変更などの対応を取ることができることから、不正利用などによるデータ侵害を未然に防ぐことが期待できそうです。

参考：『Google Security Blog “Protect your accounts from data breaches with Password Checkup”』

皆さん、こんにちは。

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

最近、ウェブサイトのパフォーマンスが微妙に落ちているように思えたこともあり、改めてCDN（content delivery network）を使った実証実験をしてみました。

CDNが効果的か否かの追求

約1年前に投稿した『CDNが速度的に逆効果となる時』という記事では、昨今のホスティング会社がサーバの仕様を大幅にパワーアップさせていることなどから『CDN』がパフォーマンス的に逆効果になるケースもあることを書きましたが、あれから1年、他のウェブサイトとの比較検証結果もあり、再度テストを行ってみることにしました。

結果、CDNを使用した時の方がわずかにパフォーマンスが良かったと言えます。

ただし、私の場合はCDN側にある機能のわずかな部分しか使用していません。

幸い、契約しているサーバがある程度活躍してくれているため、CDN側にて新たに追加された機能のみをプラスαする程度しか必要なかったのです。

つまり、元からあった機能は使用していないということです。

このように、CDNも進化していますので、たまにはCDN側の機能もチェックし、機能追加などがされているようであれば何パターンかテストしてみるのも良いと思います。

そして、CDNを使用した時のパフォーマンスが使用していない時と比べて同等以上と判断できればCDNの使用もありと言えます。

セキュリティ面でのメリットもありますから。

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

皆さん、こんにちは。

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

ウェブサイト（ホームページ）を公開している会社や店舗であれば、自社や自店のウェブサイト（ホームページ）にどれくらいのアクセスがあるのかが気になるところです。

しかし、その中に自社や自店からアクセスしたものも含めていては正確なアクセス数に大きな誤差が生じる場合があります。

WAN側のIPを定期的に見直す必要性

ウェブサイト（ホームページ）のアクセス解析を行う場合、多くはGoogleのAnalytics（アナリティクス）が使われていますが、それに何も設定をしなければ全てのアクセスが含まれてしまうため正確なアクセス数とは言えないことが多いのも事実です。

つまり、自社や自店の従業員・スタッフがアクセスした数まで含まれてしまうため、大幅にアクセス数が増えてしまっていることも考えられます。

これはAnalytics（アナリティクス）の管理上でフィルタリング設定を行うことで除外できますが、問題なのは自社や自店で契約しているインターネット回線のWAN側IPアドレスです。

どういうことかと言うと、中小・零細企業、小規模事業者の多くは固定IPアドレスの契約をすることは少なく、OCNやauなどのプロバイダから割り当てられる動的なIPアドレスを使用することになります。

これが今日の本題です。

プロバイダから割り当てられる動的なIPアドレスはある日突然変わることがあります。

例えば、プロバイダ側で設備メンテナンスがあったとか、影響する部分において障害が発生したとか、自社や自店付近などにおいて停電があったとかによる影響を受けます。

このような場合、自社や自店に設置されているルータはIPアドレスを取得し直すため、WAN側のIPアドレスが変わってしまうことがあるのです。

それ以外にも、セキュリティ的な観点から一定期間を経過すると割り当てているIPアドレスの割り当て直しを行うこともあり、WAN側のIPアドレスが変わってしまうのです。

これを把握しないまま放置していると当然ながらアクセス解析に影響しますので、定期的にWAN側のIPアドレスを確認し、変わっていたのであればAnalytics（アナリティクス）のフィルタ設定にて除外しているIPアドレスを変更してあげる必要性があります。

皆さん、こんにちは。

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

多くの会社やお店には『ウェブサイト（ホームページ）』があると思いますが、それに対して『保守契約』はされていますか？

もしされていないのであれば損をしているかもしれません。

WEBの保守契約を嫌うと損をする

毎月、もしくは年単位で一括など、保守料を支払わなければいけないということを嫌うユーザーは結構います。

当然、お金を支出するわけですから喜ばしい話しではありませんが、その考え方は損をする可能性もあります。

何故？と思われた方、そのウェブサイト（ホームページ）は何のために制作してもらったのですか？

永遠に何も更新をしないつもりで制作してもらったのですか？

本来、ウェブサイト（ホームページ）は情報を更新していかないといけません。

これはSEO（検索エンジン最適化）対策を行っていなくてもです。

従って、制作してもらう時点でそれを育てていくことが前提だという認識を持った方が良いです。

知人が制作を受託したユーザーにこんな方がいました。

『毎月コンスタントに保守をしてもらうことがないので必要な時にスポットでお願いする。』

そして、必要になった時にはこうです。

『少しメンテナンスしてもらうだけなのに金額が高い。』

これ、その時のスポットメンテナンス料金は5,000円だったそうですが、全くもって高い料金ではありません。

年間保守契約をせず、必要な時だけスポットで依頼をするわけですから割高になるのは当り前の話しです。

（この会社の財政状態は相応に余裕がありました。）

そして、結果的にはベースに使われていたWordPressのアップデート更新（メジャーアップデート）すら行ってこなかったため、ある時アップデートが行えなくなってしまいました。

WordPressで使用しているデータベースがミスマッチとなってしまい、データベースを最新の状態にあわせない限りアップデートが行えなかったのです。

（WordPressはアップデート更新時にデータベースの更新を行うことがありますので、データベースもアップデート可能な状態にしておかないとWordPress本体のアップデートが行えなくなります。）

この後どうなったかはご想像にお任せしますが、ウェブサイト（ホームページ）であっても保守契約を嫌うとこのような顛末になってしまうこともあります。

いかがでしょうか？

保守契約を嫌うと損をするという意味がご理解いただけましたでしょうか？

人は工業製品の保守料は平気で支払う割には人の作業に対しては対価を支払うことを嫌がる傾向にあります。

物が存在しないからです。

しかし、自社内で解決できず外部に依頼せざるを得ないのであれば仕方のないことではないでしょうか。

ご自身が逆の立場であればきっと同じことを思われるはずです。