皆さん、こんにちは。

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

冒頭に書いた『HSTS Preload List Submission』は登録できなかったとしても特別問題はないのですが、『共用サーバ』を使っている場合には登録できないケースがあったりします。

HSTSのPreload Listが登録できない

『共用サーバ』の場合、全く知らない個人や事業者が同一のサーバに同居していますが、そのすべてのユーザーが適切に『HTTPS化』できているとは限りません。

その場合にホスティング会社はどのようなセッティングをするか？

『HSTS』は使えても『includeSubDomains』や『Preload』を無効にすることがあります。

理由として、『HTTPS化』への対応が適切にされていなかったりすることで表示上の問題が発生するケースがあるからです。

その場合、『HSTS Preload List Submission』の要件にある『includeSubDomains』と『Preload』が満たせないために登録できないということになります。

これを何とかしたい場合には以下の内容を『.htaccess』に記述してみて下さい。

<IfModule mod_headers.c>

Header always unset Strict-Transport-Security
Header set Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
</IfModule>

これで何とかなるケースがあります。

また、『www』サブドメインで正規化している場合、『.htaccess』でのリダイレクトではなくhtmlの『meta refresh』を使ったリダイレクトでないとうまく行かないことがありますので、苦肉の策ではありますがそれを使います。

（Googleは『meta refresh』を推奨していませんが、『やむを得ない場合』にはNGとはしていないので問題ないかと思います。）

皆さん、こんにちは。

業務改善を行う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サーバーの『Apache』が『Apache 2.4』からアクセス制御の記述方法が大きく変わっていることを。

Apache2.4におけるアクセス制御

『.htaccess』などに記述するアクセス制御ですが、『Apache 2.2』と『Apache 2.4』では記述方法が異なります。

例えば、すべての要求を拒否する場合に『Apache 2.2』では

Order deny,allow
Deny from all

と記述していましたが、『Apache 2.4』では

Require all denied

と記述します。

ただし、多くのホスティング会社では従来の『Apache 2.2』の記述方法でアクセス制御が可能となるよう、『Apache』に『モジュール』を追加して対応していると思われます。

それならば問題はないのでは？

となるところですが、

サーバーの高負荷などが原因でその『モジュール』が正常に動作しないことが発生すれば別です。

『500 Internal Server Error』となりWebサイトが表示されなくなります。

つまり、そういったエラーの要因を一つでも減らしておくには『Apache 2.4』の記述に変更すべきと言えるわけです。

明日に続く。。。

皆さん、こんにちは。

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

昨日、『CDNが効果的か否かの実証実験』という記事にてCDNを改めて検証した結果をお伝えいたしましたが、その際、WordPressを使用している場合のPHP設定に注意したいことがあります。

CDNを使用したWordPressのPHP設定

CDNを使用している場合のWordPressにおいて、PHPの設定で少々問題が生じるものがあります。

以前、『WordPress更新で注意する.ini』でご紹介した『output_handler』に『ob_gzhandler』を用いた場合です。

これ、CDNを使用していない場合においてもWordPressの本体やプラグインの更新で『更新が止まっているように見える』という現象を引き起こしていたものですが、現在の『WordPress 5.0』以降では現象が起きない状態に戻っています。

ただし、『WordPress 5.0』以降であっても『WordPress 4.7』、『WordPress 4.8』、『WordPress 4.9』あたりの時のように現象が起こってしまうことがあります。

それが『CDNを使用している時』です。

これが『php.ini』、『.htaccess』、『httpd.conf』、『.user.ini（PHP5.3以降の場合）』で設定されている場合はコメントアウトするなどして対処されれば現象は起きないと思われます。

皆さん、こんにちは。

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

冒頭に書いた記事を投稿したのが『WordPress 4.6』あたりの時ですが、その後の『WordPress 4.7』や『WordPress 4.8』以降においてアップデート更新時に『更新が止まっているように見える』現象を引き起こすものがありそうです。

WordPress更新で注意するディレクティブ

さて、今回新たにWordPressのアップデート更新にて『更新が止まっているように見える』現象を引き起こす可能性のあるものですが、それは『output_handler』に『ob_gzhandler』を用いた場合です。

『output_handler』は『スクリプトの全ての出力を関数にリダイレクトすることができる』もので、モード的には『PHP_INI_PERDIR』になるため、『php.ini』、『.htaccess』、『httpd.conf』、『.user.ini（PHP5.3以降の場合）』で設定可能なものです。

このディレクティブに『ob_gzhandler（出力バッファをgzip圧縮するためのもの）』という値を指定していた場合に『更新が止まっているように見える』現象を引き起こす可能性があります。

これは、特定のWordPressバージョンにおいてしか起こらない可能性もあります。

『WordPress 4.7』、『WordPress 4.8』、『WordPress 4.9』あたりは現象が起こる可能性が高い感じがしますが、『WordPress 5.0』以降においては現象が起こらない、問題が発生しない状態に戻っている可能性が高いと思われます。

ご参考までに。

皆さん、こんにちは。

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

さて、今日は数日前にご紹介したPHP5.6系のパフォーマンス改善の続きです。

前回はPHPのコア部分に関するチューニングでしたが、今日は拡張機能部分に関してご紹介します。

PHP5.6系のパフォーマンスチューニング２

前回のコア部分では、以下の3つのことに関して触れました。

１．『output_buffering』

２．『memory_limit』

３．『replath_cache_size』

これにプラスαで、『OPcache』や『APCu』が使える（編集可能）のであれば、それも使ってみると良いです。

では、『OPcache』から。

『OPcache』が使える（編集可能）場合、以下のようにphp.ini（.user.ini）を編集してみてください。

※　他のシステムに影響を与えないようにしたい場合、可能な限り『.user.ini』を作成し、そこに記述することで全体への適用を避けられます。ただし、『PHP_INI_SYSTEM』項目はphp.iniでしか変更できません。また、サーバシステム側で制御されている場合には変更できません。

zend_extension = /path/opcache.so（例です）

opcache.enable = 1

opcache.enable_cli = 1

opcache.memory_consumption = 128

opcache.interned_strings_buffer = 8

opcache.max_accelerated_files = 4000

opcache.revalidate_freq = 60

opcache.fast_shutdown = 1

次に、『APCu』が使える（編集可能）場合、以下のようにphp.ini（.user.ini）を編集してみてください。

extension = /path/apcu.so（例です）

apc.enabled = 1

apc.enable_cli = 1

apc.shm_size = 64M

以上のような感じになります。

ただし、これらはCGI版（FastCGI版）での書き方になりますが、サーバがモジュール版PHPを採用しているのであれば『PHP_INI_SYSTEM』項目が大半ですので、.htaccessでの対応は不可となります。

つまり、モジュール版PHPが採用されている場合、サーバシステム側での設定のままということになります。

＜参考＞

『OPcache』は高性能なPHPアクセラレータで、パフォーマンスを向上させます。

『APCu』はユーザーキャッシュ機能を持ち、翻訳処理などの最適化処理に役立ちます。

皆さん、こんにちは。

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

少し前に、『PHP7.2系のパフォーマンス他』という記事ではPHP7.2系のパフォーマンスなどに触れ、『EC-CUBE2.13系のPHP7対応』という記事ではEC-CUBE2.13系のPHP7対応が未だ開発者向けのαバージョン状態であることに触れました。

では、PHP5.6系ではパフォーマンス面を諦めるしかないのでしょうか？

PHP5.6系のパフォーマンスチューニング

PHP5.6系とは言え、まだ諦める必要はありません。

それなりにチューニングしてあげることによってある程度パフォーマンスは向上します。

まず、php.ini（.user.ini）を以下のようにしてみてください。

※　他のシステムに影響を与えないようにしたい場合、可能な限り『.user.ini』を作成し、そこに記述することで全体への適用を避けられます。ただし、『PHP_INI_SYSTEM』項目はphp.iniでしか変更できません。また、サーバシステム側で制御されている場合には変更できません。

１．『output_buffering』の値を『On』もしくは『4096』としてみてください。

例：output_buffering = On（output_buffering = 4096）

２．『memory_limit』の値をデフォルトの『128M』より大きくしてみてください。

例：memory_limit = 1280M

３．『replath_cache_size』の値をデフォルトの『16K』より大きくしてみてください。

例：replath_cache_size = 4096K

これらはCGI版（FastCGI版）での書き方になりますが、サーバがモジュール版PHPを採用しているのであれば、.htaccessに記述することで対応可能です。

ただし、『PHP_INI_SYSTEM』の場合は.htaccessでの対応はできません。

１の例：php_flag output_buffering On（php_flag output_buffering 4096）

２の例：php_value memory_limit 1280M

３：.htaccessでの対応不可

これ以外に『OPcache』、『APCu』が使え、その設定が変更可能なサーバを使われているのであればまだプラスαがありますので、後日改めてご紹介したいと思います。

そのラボにおける活動の第一弾として、『日本国内におけるWordPressセキュリティの現状』の分析レポートが公開されています。

皆さん、こんにちは。

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

冒頭に書いたラボが公開した分析レポートにおいて、WordPressへの攻撃（検出箇所）として以下のものが最多として書かれていましたのでご紹介します。

WordPressへの攻撃で最多のものとは

WordPressへの攻撃（検出箇所）で検出が最も多かったものは、『xmlrpc.php』というものです。

『XML-RPC』というのは、遠隔での呼出しを行うプロトコルの一種で、WordPressで言えば、通常の管理画面以外からの投稿を可能にするものです。

WordPressの場合、スマホアプリなどのXML-RPCを使った更新にも対応しているため、xmlrpc.phpというファイルが用意されています。

これが使用可能になっているとどうなるのか？

xmlrpc.phpをターゲットとしたDDoS攻撃などの被害に遭う可能性があり、それを受けた際にはサーバが高負荷状態でパンクしてしまうことにもなります。

つまり、アクセスできない状態にされてしまう恐れがあるということです。

では、これを避けるための対策法はどのようにすれば良いのか？

xmlrpc.phpファイルへの攻撃の対処法

WordPress3.5未満においては管理画面の投稿設定にxmlrpcを無効にするチェックボックスがあったのですが、WordPress3.5以降のバージョンではそれがなく（現在の最新は4.9.4）、デフォルトで有効な状態にあります。

その場合、一番簡単な方法は『.htaccess』でxmlrpc.phpへのアクセスを禁止してしまう方法です。

<Files xmlrpc.php>

Order allow,deny
Deny from all
</files>

と、記述を追加すればOKです。

どうしても特定のIPアドレスからのみ許可をしたい場合、

<Files xmlrpc.php>

Order allow,deny
Deny from all
Allow from xxx.xxx.xxx.xxx
</files>

と、赤字の部分を加えればOKです。

これ以外に、多少サーバへの負荷が残るものを考慮したいのであれば以下の方法が良いです。

<IfModule mod_rewrite.c>

RewriteEngine On
RewriteBase /
RewriteRule ^xmlrpc\.php$ “http\:\/\/0\.0\.0\.0\/” [R=301,L]
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

というように、WordPressで.htaccessに設定される記述に赤字の部分を追加し、xmlrpc.phpへのアクセスを0.0.0.0にリダイレクトさせてしまう方法もあります。

ちなみに、プラグインを使って無効化する方法もありますが、プラグインそのものに脆弱性が見つかることもあるためお勧めではありません。

皆さん、こんにちは。

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

以前にご紹介した記事の中では、GeoIPやGeo Liteを使って海外からのアクセスを拒否する方法を書きました。

今日は、それらが使えない場合などにおける他の方法をお伝えします。

海外からのアクセスをIPアドレスでブロック

日本国内向けに公開しているウェブサイトにおいても、海外から迷惑なアクセスが多発することがあります。

特に、WordPressなどのCMS（Content Management System/コンテンツマネジメントシステム）を使っているウェブサイトにおいてはそれが目立ちます。

このような場合、アクセス元のIPアドレスを個別で指定するのではなく、サブネットマスクを付けて一定範囲を指定する方が効果があります。

例えば、アクセス元のIPアドレスが10.8.6.4だったとした場合に、以下のように.htaccessに記述します。

order allow,deny

allow from all
deny from 10.8.6.0/24

そうすると、10.8.6.0-10.8.6.255（256個のIPアドレス）の範囲をブロックすることができます。

これが、

order allow,deny

allow from all
deny from 10.8.6.0/16

であれば、10.8.0.0-10.8.255.255（65536個のIPアドレス）の範囲をブロックすることができます。

ただし、これらは事前にIPアドレスのデータベースなどにて調べる必要があります。

その調べた結果がすべてブロックしたい国のIPアドレスであれば大丈夫です。

※　サブネットマスクの計算は、インターネット上にサブネットマスク計算のサイトが公開されていますので、それを使うと簡単にできます。

皆さん、こんにちは。

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

よくある話しですが、ウェブサイトのメンテナンスにおいて修正が反映されないことがあります。

これは、修正したファイルがアップロードしても置き換わっていないのではなく、いくつかの要因で反映していないように見えるのです。

ウェブサイトの更新が反映されないケース

ウェブサイトのメンテナンスが反映されないケースとして、以下のことが考えられます。

１．ブラウザがキャッシュしているものを読み込んでいる

２．.htaccessにブラウザキャッシュの記述がされている

３．WordPressなどのCMSのキャッシュ系プラグインがキャッシュしたものを読み込んでいる

４．CDNがキャッシュしているものを読み込んでいる

これらに対する対処法は、以下のように行えば更新が反映されます。

１の場合はブラウザの更新ボタン、もしくはF5キーを押すか、キャッシュのクリアを行う

３の場合はCMSのキャッシュ系プラグインのキャッシュをクリアする

４の場合はCDN側のキャッシュをクリアし、CDN側でのブラウザキャッシュの設定も一度0にする

２に関してはあまり影響しない、もしくはブラウザの更新やキャッシュのクリアで回避されるのですが、すべてを行っても反映されない場合、.htaccessに記述されているブラウザキャッシュの部分を一度コメントアウトするなりしてみてください。

想定外のところに影響しているケース

上記のケースの1つとして、少々想定外的なケースも存在します。

例えば、ウェブサイトの一部分だけにWordPressなどのCMSを導入し、大半はhtmlにて構成されているウェブサイトで、そのhtml内にてWordPressなどのCMSに書かれている記事のタイトルなどを読み込んでいる場合、WordPressなどのCMSで使われているキャッシュ系のプラグインが影響することがあります。

WordPressなどのCMSの一部ではないので関係がないと思うかもしれませんが、こういったケースもあり得ます。

その場合、前述の３の時と同じく、WordPressなどのCMSのキャッシュ系プラグインのキャッシュをクリアすることで反映するようになります。

もしウェブサイトのメンテナンスにおいて、アップロードしたものが反映されない場合には一度お試しください。