皆さん、こんにちは。

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

さて、連日のように『新型コロナウイルス感染症』の話題がメディア中を埋め尽くしている日々ですが、そんなご時世もあって今、『Zoom』というコミュニケーションツールが注目されています。

テレワークで注目されるZoomとは

『Zoom』とは、ビデオ会議やウェブ会議を行うためのツールです。

事業用のプランには『無料』、『小規模向け』、『中小企業向け』、『大企業向け』があり、『無料』プランであっても100人の参加者までホスト可能となっています。

そのほか、1対1ミーティングは無制限に行え、40分までのグループミーティング（ミーティング数の制限なし）、ビデオ会議、ウェブ会議、デスクトップとアプリケーションの共有など、ちょっとした打ち合わせであればこれで十分と言えます。

従来、このようなビデオ会議ツールで無料プランを選択した場合、参加人数が増えると動作が不安定になったり、参加人数の上限が少なかったりしますが、『Zoom』は高音質・高画質、しかも最大100名まで参加が可能というところが特徴とされています。

ある調査によると、『テレワーク』の実施は一部の企業にとどまっているようで、中小・零細企業、小規模事業者においては予算的な問題や知識的な問題で実施できていないというのが現状のようですが、まずはこのような『無料』で実施できるところから『やってみる』ということが重要なのではないでしょうか。

『Zoom（ビデオ会議・ウェブ会議）』

皆さん、こんにちは。

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

既に『TLS1.0』と『TLS1.1』は多くのサービスで終了がアナウンスされており、現在の中心は『TLS1.2』となります。

しかし、それよりももっとセキュリティ的に安全で高速なのは『TLS1.3』での通信です。

TLS1.3対応で安全で高速な通信が間もなく

『Google Chrome』や『Mozilla Firefox』など、主要なブラウザでは既に『TLS1.3』に対応済みですが、ホストとなるサーバ側の方は一部のサーバが『TLS1.3』に対応し始めた程度の状況で、多くは未だ『TLS1.2』の状態です。

この『TLS1.3』は『TLS1.2』に比べてセキュリティ面、速度面の両面にて改善されている『暗号化通信プロトコル』であるため、早い段階で様々なところで対応がされることが望ましいわけですが、ホスト以外にも少々引っかかってしまう可能性があるものがあります。

それはセキュリティソフトです。

多くのセキュリティソフトでは各Webサイト（ページ）にブラウザからアクセスする際の通信を保護する機能が付いていますが、その部分が未だ『TLS1.2』までしか対応していないものがあります。

そのような場合、よく閲覧する『信頼できる』Webサイト（ページ）が『TLS1.3』に対応しているならばそれをチェック対象から外して通信を行うしかありません。

おそらく、各セキュリティソフトの次のバージョンにおいては間違いなく『TLS1.3』に対応したものがリリースされるはずですから、もう間もなくで環境が整ってくるのではないかと思われます。

皆さん、こんにちは。

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

今日は昨日の続きになります。

『Apache 2.4』では『アクセス制御』の記述方法が『Apache 2.2』から大きく変更されていますので、昨日に続き、今日はいくつかの記述方法をお伝えします。

Apache2.4でのアクセス制御サンプル

＜すべての要求を拒否する＞

これだけは昨日の投稿でも書きましたが念のため。

（Apache 2.2）

Order deny,allow
Deny from all

（Apache 2.4）

Require all denied

＜すべての要求を許可する＞

（Apache 2.2）

Order allow,deny
Allow from all

（Apache 2.4）

Require all granted

＜IPを指定する場合＞

（Apache 2.2）

・許可：Allow from 192.168.0.1

・拒否：Deny form 192.168.0.1

（Apache 2.4）

・許可：Require ip 192.168.0.1

・拒否：Require not ip 192.168.0.1

＜環境変数を利用する場合＞

（Apache 2.2）

SetEnvIf User-Agent “Googlebot” Allowbot
Allow from env=Allowbot

（Apache 2.4）

SetEnvIf User-Agent “Googlebot” Allowbot
Require env Allowbot

こんな感じになります。

少しまとめてみると『Apache 2.4』では以下のようになります。

・すべてを許可：Require all granted

・すべてを拒否：Require all denied

・個別指定で許可：Require ip 192.168.0.1 / Require host example.com / Require env example

・個別指定で拒否：Require not ip 192.168.0.1 / Require not host example.com / Require not env example

＜条件ディレクティブ＞

今まで記述したものに加え、『Apache 2.4』では以下の『ディレクティブ』を使って条件を指定できます。

・RequireAll：すべての条件にマッチすれば許可

・RequireAny：条件に一つでもマッチすれば許可

・RequireNone：条件に一つでもマッチすれば拒否

例えば、Basic認証でIPアドレスも条件に加えた場合、

<RequireAll>
Require user admin
Require ip 192.168.0.1
</RequireAll>

（AuthUserFile、AuthGroupFile、AuthName、AuthTypeなどはApache 2.2と同じです。）

といった感じになります。

ご参考までに。

しかし、パソコンの電源を落としてしまった後、再度パソコンを立ち上げるのは面倒だったりもします。

皆さん、こんにちは。

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

Webの関係で、場合によっては『SSH』などを使ってリモート操作を行うことがあったりしますが、既にパソコンの電源を落としてしまった後にやるべき作業に気付いた場合、あなたならどうしますか？

iPhone向けのSSHターミナルアプリ

既に使っている方もいるかとは思いますが、iPhoneやiPadで使える『SSHクライアント』があります。

その中でもお勧めは『Terminus』というアプリです。

設定は簡単です。

１．App Store から『Terminus』アプリを入手します（無料です）。

２．『Terminus』でSSH用のKeyを作成します（PCとは別にした方が良い）。

３．新しく作成された公開キーをサーバの『authorized_keys』に追加します。

４．『Terminus』でホストの追加を行います（Keyは作成したものを選択）。

５．ホストに接続します。

これでパソコンからリモート接続している時と同じ状態ができ上ります。

これ、結構便利です。

本来は出張中などで職場以外の場所からアクセスしなければいけないようなケースを想定しているようですが、使い方によっては『1つやることを忘れたのにパソコンの電源落としてしまった！』という時にも良いと思います。

興味のある方は是非使ってみて下さい。

皆さん、こんにちは。

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

昨日でしたでしょうか、早くもWordPressの更新版『WordPress 5.0.1』が公開されました。

今日はそのニュースをお伝えします。

WordPress 5.0.1への更新を強く推奨

WordPressのブログニュースを見る限り、今回のリリースは『WordPress 3.7以降のすべてのバージョン』に対するセキュリティリリースで、『すぐにサイトを更新することを強くお勧めします』とされています。

リスクを考えると、『WordPress 5.0″ベボ”』へのアップデートを様子見していた方もアップデートせざるを得ないとも言えます。

以下、発見された脆弱性の内容です。

１．著者が許可されていないファイルを削除するためにメタデータを変更できてしまう

２．著者が特別に細工された入力で許可されていないタイプの投稿を作成できる可能性がある

３．コントリビュータがPHPオブジェクトインジェクションの結果としてメタデータを作成できてしまう

４．コントリビュータがより高い権限を持つユーザーからの新しいコメントを編集し、クロスサイトスクリプティングの脆弱性を招く可能性がある

５．特別に細工されたURL入力が、状況によってはクロスサイトスクリプティングの脆弱性を引き起こす可能性がある

（WordPress本体は影響を受けていなかったが、プラグインはいくつかの状況にある可能性がある）

６．ユーザーアクティベーション画面を検索エンジンで索引付けすることができ、電子メールアドレスの公開につながり、場合によってはデフォルトのパスワードが生成される

７．Apacheホストサイトの作者がMIME検証をバイパスする細工されたファイルをアップロードし、クロスサイトスクリプティングの脆弱性を引き起こす

早めの段階でWordPress 5.0.1へアップデートされることがお勧めです。

皆さん、こんにちは。

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

EC-CUBEにおいても、『sendmail』ではなく『SMTP』で送信したい！という方もいます。

そのような場合、少しだけ内部設定を変更してあげれば『SMTP』で送信することが可能です。

では、どこを編集・変更したら良いのでしょうか？

EC-CUBE2.13系におけるSMTP送信

例えば、GmailのSMTPを用いた場合、以下のように設定する必要があります。

（他のSMTPでも、ホスト、ユーザー名、パスワードを変更すればOKです。）

１．/data/config/config.php

define(‘MAIL_BACKEND’, ‘smtp’);
define(‘SMTP_HOST’, ‘tls://smtp.gmail.com’);
define(‘SMTP_PORT’, ‘465’);
define(‘SMTP_USER’, ‘ユーザー名（メールアドレス）’);
define(‘SMTP_PASSWORD’, ‘パスワード’);

２．/data/module/Mail/smtp.php

var $host = ‘tls://smtp.gmail.com’;
var $port = 465;
var $auth = true;
var $username = ‘ユーザー名（メールアドレス）’;
var $password = ‘パスワード’;

この2つのファイルに対して記述を編集する必要がありますが、1つポイントがあります。

SMTPのホスト部分は『tls://』を付与することです。

これを入れておかないとエラーになります。

また、ポートが『587』の場合にはうまくいかない話しもありますので、『465』がお勧めです。

ご参考までに。

皆さん、こんにちは。

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

日本時間の昨日、WordPressの更新版であるWordPress4.9.5が公開されました。

今日はそのニュースをお伝えします。

WordPress4.9.5セキュリティ・メンテナンス

WordPressのブログでは、以下のように説明されています。

WordPress 4.9.5 がご利用いただけるようになりました。これは WordPress 3.7 以降のすべてのバージョンに対するセキュリティ・メンテナンスリリースとなります。今すぐにサイトの更新を行うことを強くおすすめします。

バージョン 4.9.4 以前の WordPress は、3つのセキュリティ問題の影響を受けます。コアチームの継続的なセキュリティ強化の取り組みにより、4.9.5 では、次の修正が実装されました。

１．デフォルトで localhost を同じホストとして扱わない。
２．SSL が強制されている場合に、ログインページのリダイレクトに安全なリダイレクトを使用する。
３．ジェネレータータグでバージョン文字列が正しくエスケープされていることを確認する。

WordPress 4.9.5 では、その他25個のバグが修正されました。特筆すべきは、以下となります。

・キャプションショートコードで以前のスタイルが復元されました。
・タッチスクリーンデバイスでクロッピングがサポートされるようになりました。
・エラーメッセージなどの文字列がより明解となるよう更新されました。
・アップロード中の添付ファイルのプレースホルダーの位置が修正されました。
・REST API JavaScript クライアントのカスタムノンス機能が、コードベース全体で一貫したものとなりました。
・PHP 7.2 との互換性が向上しました。

注意したいのは、『WordPress4.9.3で嫌な不具合』でご紹介した通り、WordPress4.9.3において自動バックグラウンド更新をサポートするサイトが自動的に更新されないというバグ（不具合）があったため、手動で4.9.4にアップデートされていない場合は4.9.5に自動更新されることはないと思われますので、念のため管理画面で確認をしておくことをお勧めします。

皆さん、こんにちは。

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

冒頭に書いたIMAP受信でメールを閲覧している方、サーバの移動の際は少々手間な部分もあります。

サーバ移動の時のIMAPメール

IMAP受信の場合、受信したメールは端末側にはないため、サーバにアクセスして受信メールを閲覧することになります。

ということは、サーバが移動した場合、基本的には受信メールはなくなってしまうに等しいことになります。

従来はAというサーバを閲覧していたものが、次はBというサーバを閲覧することになりますので、元々Aというサーバにあった内容は自動的にはBに移動しません。

こういった場合、管理者がすべてをAからBに移動してくれない限り少々作業が発生します。

１．端末にAのサーバをホストとしたPOP受信のアカウントを追加する

２．１の設定で新たに追加されたアカウントで端末にメールが受信されます

３．送信済みメールや分類したメールなどを１で作成したアカウントにコピーします

４．IMAP受信していたアカウントを新サーバーのホストに変更します

５．２と３でPOP受信のアカウントにあるメールデータをIMAP受信のアカウントにコピーします

上記のような作業が必要になることがあります。

また、念のためPOP受信用に作成したアカウントはしばらく残しておいた方が良いでしょう。

ご参考までに。

皆さん、こんにちは。

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

非常に迷惑なスパムメールは、日々大量に、かつ無作為に送られているわけですが、これらのスパムメールに対してもある程度は対処できます。

ではいったいどのように対処していけば良いのでしょうか？

レンタルサーバの2つのケース

レンタルサーバの中には、迷惑（スパム）メールをフィルタリングしてくれるオプション機能を用意しているところと、迷惑メール（スパム）メールを自分でカスタマイズできるようにしているところがあります。

前者の場合、迷惑（スパム）メールをフィルタリングしてくれるオプションを契約すればある程度解決する可能性があります。

しかし、このケースの場合は自社に届く迷惑（スパム）メールにあわせて調整することはできません。

一方後者の場合、契約するだけで迷惑（スパム）メールをフィルタリングしてくれることはありませんが、自社に配信されてくる迷惑（スパム）メールにあわせたカスタマイズが可能です。

では、迷惑（スパム）メールのフィルタリングをカスタマイズできるレンタルサーバの場合にはどのようにして対処すれば良いのでしょうか？

スパムメールはアドレスをブロックしてもダメ

迷惑（スパム）メールの多くはメールアドレスが偽装されていますので、メールアドレスだけをブロックしてもあまり効果はありません。

別の偽装メールアドレスから同様の迷惑（スパム）メールがまた届いてしまいます。

まずは迷惑メールのヘッダ情報をよく見ることです。

何通も同様の迷惑（スパム）メールが送りつけられてくる場合、ある程度は共通するところがヘッダ情報から見つけることができます。

例えば、From（送信者）とReturn-Path（返信先）などがabc@xxx.comであったりxyz@yyy.comであったりしていても、Received from（送信したパソコン名やホスト名など）が共通してzzz.comであったりします。

この場合、共通したzzz.comがヘッダにある場合のメールをブロックする設定をしてあげることが有効的です。

絶対にやってはいけないこと

自社に全く関係のない迷惑（スパム）メールが届いた場合、そこに書かれているリンク先をクリックすることや添付ファイルをクリックすることは絶対にやってはいけません。

迷惑（スパム）メールを送りつけてくる相手の目的は、リンクをクリックさせること、もしくは添付ファイルを開けせることにあります。

それにより、変なウェブサイトに誘導されてしまったりウイルス感染してしまうといったトラブルに見舞われてしまいます。

このことに注意し、適切なブロック設定をしてあげることである程度は迷惑（スパム）メールを減少させることは可能です。

ただし、海外のサーバを経由しているものやボットネットの踏み台になってしまっているものもありますので、なかなか解決が困難なものも存在することは事実です。