SSLサーバ移転に注意すべきこと(転送mod_rewriteが効かない場合の考察)

昨年(平成30年)からSSL仕様にする流れが大きくサーバトラブルの要因となるケースが発生している、特にサーバ移転や表示ドメインの変更時に注意が必要だ。これは何を意味しているかというと、概ね以下の問題点が出てくるためである。

SSLでサーバ移転で生ずる問題

  1. 旧httpドメインでのアクセスを取りこぼしたくないから転送処理を導入するが期待通りに動作しない
  2. SSL証明書をwww付きで取得するか、無しで取得するかでWEBサーバ設定やmod_rewrite等が影響を受ける
  3. 転送のキャッシュ、証明書のキャッシュは「強制リロード」、「履歴の削除」、「キャッシュの削除」では消えない場合がある。


SSL証明書を購入するときに注意をしないといけないのは「www]付きのドメインなのか否かである。SSL証明書発行局のブランドにより1つの証明書で「www付き」と「www無し」をサポートしてくれるものが中にはある。申請時点でwww.xxxx.comのようにコモンネームにwwwをつけた場合(あり・なしを双方サポート)するパターンがあるので申請時にどのコモンネームにするかはよく考えたほうが良い。以前はwww.xxxx.comだったがサーバ移転のタイミングでSSLにしてwww無しで行こうと考える場合は一番注意が必要だ。

つまりwww無しにしたとして、旧ドメインはwww付きであるためユーザの中には旧ドメインでアクセスしてくるものもいるだろう。それを取りこぼししないようにmod_rewriteを使ってwwwで来たものを無しに転送するといった手法は古くからある。しかし、SSLが絡んでくると複雑な状況になる。というのもSSLが付いているサーバアクセスではブラウザー側の挙動が転送処理をチェックする前にSSLのチェックを先に実施するパターンがあるからだ。

ここで発生する問題はwww無しでSSL取得したが、以前はwwwが付いていたのでそれをどうやって取りこぼしをしないように統合するかである。結論を先に言ってしまうと残念ながらSSL証明書はwww付きとwww無しの双方をサポートするSSL商品を購入するか、www付きとwww無しを個別に2つ購入するしかない。

その理由はブラウザー側にあり、SSLでアクセスするモードでは転送処理より優先してSSLチェックが発生するからである。chrome,opera,vivaldi等では転送前にSSLチェックは生じないがedge,safari,firefoxではSSLチェックが転送より先に発生するのである。つまり転送処理をいくら入れてもwww付きSSLがなかったり、wwwドメインがサイトに存在しないと「セキュリティに問題があるサイト」という判定になってしまうため転送まで行き着かないのである。

最新WORDPRESSマルウェア感染事情

WORDPRESSのマルウェア感染は、年々酷くなっているように感じています。これは政府のセキュリティへの関心を促す動きとは逆行していますが事実です。セキュリティへの関心はサイトを運営する人にとっても、かなり意識の向上は感じるのですが結果を見ると芳しくない状況です。それはユーザのセキュリティソリューションへの過度な期待が裏側にあると思うのです。

WORDPRESSはホームページを作成する有益なCMSとして世界ナンバー1ですが、残念ながらプログラムにマルウェア感染したサイトもWORDPRESSが非常に多い。脆弱性対策を促進するためにWORDPRESSのバージョンをアップさせなさいと様々なネットや記事でも取りざたされているわりに一向に感染は減らない状況と言えます。

実はここにトリックがあるのです。厳密に言うとWORDPRESSのシステムの脆弱性というよりはプラグイン、テーマファイル、利用ユーザの使い方と環境に問題があるため感染しているケースが多いと思います。

まずユーザが認識を改めるべきは、プラグイン、テーマファイルはマルウェア、スパイウェアのバックドアの巣窟なのだということ。ユーザが自由にカスタマイズしてWORDPRESSのシステムが及ばない世界(認知しない)だから防ぎようがない範囲なのです。

多くの運営者はCMSの管理画面ログインの防御を真っ先に考えます。しかし昨今のマルウェア感染状況を見る限りでは管理画面ログインやフォルダーを固定IPでブロックしても改竄はなくなっていません。この理由は簡単でプラグイン、テーマファイル、アップロードフォルダーはセキュリティ制限が緩い状況にあるからです。認証が生じない、IP制限が及ばないとなると予め不正な事ができるプラグインやテーマファイルをユーザにインストールさせてしまえば、バックドアを仕掛けるのは簡単。

WORDPRESSの中には新規でプラグインやテーマを検索&インストールする機能がありますがそこに登録されているものはすべて安全と考えるのは早計です。公式サイトに登録時に厳しいいチェックが入っているわけではないので導入はユーザの自己責任となっています。

また、仮に登録時にマルウェアスキャンをかけても検知されないようなアプローチもあります。そのケースは不正コードを暗号化したり、コードをシュレッドして分散することで見つからないようにしています。結局不正コードをいつでもアップロード、あるいはイネーブルにして外部から操作できる仕組みを導入しているためドキュメントルート直下のファイルやWORDPRESSのシステムファイルも改竄きてしまいます。これらは固定IPブロックや管理者ログインを制限しても無駄なのです。

このケースでは、1サーバに複数のドメインサイトを保有している環境で試しにそのうちの1つの仮想サーバを停止して、停止したサイトのフォルダーが改竄されるか実験してもたことがあります。結果は仮想サーバを停止しても該当ドメインのフォルダー配下のファイルは改竄されました。もはやWEBの仕組みで改竄スクリプトを動かしているのではなくLinuxOSの仕組みで改竄を行ってることがわかります。こうなってくると他の感染源となっているドメインサイトをクリーニングしないと改竄は止まりません。

GoogleのreCAPTCHAのバージョンがVersion3になってチェックが不要に。

私ごとで恐縮ですが、たまたまフランスからコンタクトフォームからスパム投稿があった。
なんだろう?なぜだろう?と思いながらホームーページを調べていたら設定していたはずのGoogleのreCAPTCHAは効かなくなっている。

どうしてだろう?と思い調べてみるとContactForm7の最新版プラグインはreCAPTCHAのバージョンが上がっており、プラグインを更新した際に
以前のreCAPTCHA(v2)が使えなくなっていた。つまりreCAPTCHA(v3)を使いなさいということです。

どうやら再度、新規登録をGoogleのreCaptcha登録サイトで行わないと利用できない。そこで登録した際の「サイトキー」と
「シークレットキー」が発行されるのでそれをContactForm7に登録しないといけないようになっている。

またGoogleのreCaptcha登録サイトで案内されてるJavascriptの埋め込みコードを自サイトへ2種類登録する必要がある。
コンタクトフォーム7で作成したそれぞれのプロファイルの入力HTMLコードの先頭に埋め込んでおけば良いだろう。下記の様なものを埋め込む。

実は、もう一つ盲点があってContactForm7にGoogleのreCaptchaのチェック画像が以前はあったと思うが、今回のリリースで不要になった。
そのためreCaptcha(v2)で使っていたContactForm7の埋め込みタグは不要になりました。
知らずに、どうやったらreCaptcha(v3)が使えるのか1時間ほど悩んでしまった。そのかわり右下にGooglenoの安全マークアイコンが出るように
なりました。

マルウェア感染が止まらない理由-(WORDPRESS)

WORDPRESSがマルウェアに感染するとよくやる対処は、テーマファイルを一つ一つ開けてチェックするケース、あるいはプラグインセキュリティを入れて駆除するパターンがオーソドックスな対処方法だと思う。ではこのやり方は本当に特効薬になりえるか?答えはNOだ。駆除をやったことの安心感だけかもしれない。見えない感染が実際には潜んでいることも知らずに。


感染に気付けない恐怖

前回の記事でも説明したがこのやり方では大概マルウェアは駆除できていない。見かけ上駆除できたように勘違いしてしまうのだ。一度駆除すると落ち着いたように見えるケースもあるし、すぐさま新しい改竄や挿入ファイルを差し込んでくるケースも有りパターンは様々だ。兎に角マルウェア感染への第一歩は、新しいサイトを構築する際にどれだけきちんとセキュリティ対策を講じて作るかが鍵である。つまり最初良ければ終わりよしとなる。逆に最初適当にサイトを作り、全くセキュリティ対策を講じないで公開すると何れマルウェアの巣窟になってしまう。直しても直しても感染する。あるいは、安心させて実際は感染しており攻撃ステーションとして乗っ取られている場合もある。これはひとつ間違えれば顧客の信用を落としてしまうことになるだろう。

どこを中継して改竄が起こっているのか?

これはざっくり6パターンある。

  • uploadsフォルダーへ改竄プログラムを設置(phpファイル、画像ファイルの拡張子にして設置)
  • システムファイルの脆弱性を利用して外部から差し込む。
  • プラグインの脆弱性を利用して外部から差し込む。
  • テーマファイルの脆弱性を利用して外部から差し込む。
  • テーマ、プラグイン作者が意図して脆弱性、スパイウェアを仕込んで差し込む。
  • パソコン、ブラウザに既に仕込まれたマルウェアが動き出して差し込む。

何故プラグインセキュリティ、総合セキュリティソフトではみつけられないのか?

改竄プログラムをエンコードしたり、そのコードを分割したりして判別付けにくくしている。更にプラグインセキュリティの想定以上に複雑で正規表現フィルターにひっかかりもしないものが存在する。また感染パターンや感染ファイルもダイナミックに生成されるものもあり判別を更に難しくしている。兎に角想像以上に進んだ仕組みで感染させていると感じるケースが少なからずある。私自身も片っ端からプラグインセキュリティソフトを試したが、一部は判定してくれるが、大部分がすり抜けてしまうケースが多かった。意外にもWindowsDefenderが検知してくれるものも結構あったのは驚いた。

高いマルウェアの検出はできるのか?

結論は最先端のAIと従来のヒューリスティックエンジンを搭載したPHP言語を理解できるマルウェアスキャナーでなければ検知は難しい。弊社ではいくつかのこのようなマルウェアスキャナーと目見でのチェックも合わせて高い検出を達成しています。一般的なセキュリティソフトでは検知は難しく見つかっても目立つ旧来の単純な感染パターンだけだと思います。ある意味マルウェア製作者はこういった見せ玉の感染とサイレントに見つかりにくいものを両方用意しているのかもしれない。

WORDPRESSのマルウェア対策

WORDPRESSはCMS界の中ではユーザ数が最も多いオープンソースパッケージですが、オープンソースであるがゆえに、悪い人たち(クラッカー)に研究されてマルウェアを混入されてしまう危険性も高いのが難点。サイトを構築する段階から注意を払って作成すれば問題はないのですが、感染した後だと困難が待ち受けているのも事実です。


WORDPRESSの感染をチェックする方法

  • 使用しているテーマのテーマフォルダ内にあるphpやjavascriptファイルでタイムスタンプが怪しいものを見つける。

  • ファイルサイズが変わっている?あるいは増えていると思うものを開いてコードをチェックする。感染コードは見ればすぐに分かります。
  • セキュリティプラグインを導入してマルウェアの検出。50%から70%位は検出可能です。ドキュメントルート、WORDPRESSシステム配下のチェックは概ねプラグインソフトは弱いです。
  • uploadsフォルダー配下にphpファイルが存在しないかチェックする。
  • テーマ感染は既存ファイルに感染しているのがほとんど。新規ファイルのケースは少ない。
  • ドキュメントルート直下、システムフォルダ(wp-admin,wp-includes)は既存ファイルよりも新規ファイルで感染ファイルを置くケースが多い。

  • ドキュメントルート直下、システムフォルダで既存ファイルが感染している場合はワンランク上の感染と思ったほうが良い。つまりプラグイン程度で見つけたり駆除できない

  • pluginsフォルダー内の感染は元々プラグイン自体に仕込まれている事が多い。

セキュリティプラグインで合格だったから大丈夫と思わないほうが良いです。私は高度な感染を検知できるプラグインは未だに見たことありません。

ハイレベルなマルウェア感染

高次元の感染はタイムスタンプを過去の日付時間にする場合があり、感染がドキュメントルート全体に及ぶこともあります。つまりドキュメントルート直下、wp-admin,wp-includesあたりを改ざんする手口をやっているクラッカーはそこそこ詳しい人がやっているケースが多く簡単には見つからない手法で感染させているケースがあります。

手口と対処

  • 感染中継ファイルの拡張子を任意のイメージファイル拡張子に変えて設置
  • 改竄したファイルのタイムスタンプを書き換えている。周りのファイルのタイムスタンプとかけ離れているものは怪しい。
  • 感染中継ファイルで圧倒的に多いのは/wp-content/uploadsの配下に設置されている。
  • ドキュメントルート、wp-admin,wp-includes配下の感染は例えばサイトからWindowsにファイルをコピーして持ってきた上でWindows Defenderでスキャンしても見つけられる場合が結構ある。
  • ドキュメントルート、wp-admin,wp-includes配下の感染は有料ウィルススキャンソフトでWindowsにファイルをコピーして持ってきた上でスキャン実施すると高い検知率で発見、駆除ができる。
  • ドキュメントルート、wp-admin,wp-includes配下の感染はphp専用のマルウェアスキャナーで更にスキャンするとほぼ完璧に近いレベルで発見、駆除ができる。

予防策、防御策

  • ディレクトリレベルでmd5でハッシュ値を取り、コンテンツ更新する度にハッシュ値の更新を取る。
  • 毎日、定時間にバッチを走らせ前回のハッシュ値と現在のハッシュ値に相違があるか調べる。相違があった場合は感染の疑いあり。
  • 総合セキュリティプラグインの導入。最初から導入すると効果が抜群です。
  • 編集者はできるだけ固定IPで管理画面へのアクセスを縛ること。