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

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

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

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

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

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

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

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

昔よりも更に複雑になったと思うサーバの種類にメールシステム(smtpサーバ:MTA)がある。振り返ってみると２０年くらい前はデフォルトで作ったメールサーバでもすぐにインターネット上で使えましたが、今は兎に角セキュリティが厳しいので単純な設定ではまともに動かない。ガチガチだなーと感じる。時折サーバ講義の仕事をすると一番厄介なのがメールサーバの解説。正直言って１週間勉強した程度で理解できるのは初心者程度の知識だと思う。アンチSPAMの仕組みについては年々高度になっている。油断しているとおいて行かれるので定期的に情報に目を通さなければならないが、最近の技術の中ではDMARCはさすが効果あるね！と実感できる仕組み。この機能はSMTP通信におけるなりすましを確実にブロックしてくれる。単純ななりすましなら１００％ブロックできるだろう。送信サーバがスパイウェアに感染していたら駄目だと思うが、そうなっていない限り大変安全な仕組みと思う。

DMARCを使用してよかった事

以前は、時折自分のメールアドレスFromで数は多くはなかったが１年に２，３回程度送信されてくることがあったがDMARCを導入してからはピタリと止まった。更に嬉しいことに偽メールを送られた受信メールサーバからレポートがxmlで送られてくるので実態が掴める。殆どがgmailとyahooメールからのものだが、これだけ人の名前とメールアドレスを騙って送る輩がいたのだと気付かされる。つまり実際にはもっと沢山偽メールが横行していたと考えられる。もちろんDMARCを実装しているメールサーバでなければこのようなやり取りはできないが、今後必須のシステムになってきそうだと思います。特にビジネスで利用されている企業は共有ホスティングのおまけでついてくるメールは使ってはいけないと私は思います。

DMARCの導入は難しい？

メールサーバの導入になれている人なら１，２時間の学習でDMARCは導入できると思います。DKIM,SPFを入れた経験があるならすぐに理解できると思います。少しDKIM,SPFでやったような作業がつきまといますが非常に難易度の高いものではありません。作業の中にDNSのレコードを操作する箇所があるのでDNSを知らない人は大変かもしれませんがぜひチャレンジしてみてください。CentOSでやるよりもUbuntuのほうがハードルが低そうです。

DNSBLの信頼性

DNSBLシステムは世界に点在しブラックリスト情報を収集して無料で使えるメールSPAM対策サービスが幾つかある。このサービスはDNSの仕組みを利用したレピュテーションサービス（ブラックリストの判定を返す）だが運営組織が何しろ非営利な組織だから出来ては消えての繰り返し。日本ではRBL.JPという日本のスパムデータ・ベースもあったが廃止されており、現在はほとんど海外のサービスを利用するのが多くなった。厄介なのは昨今のIPアドレス汚染だ。プロバイダーの持っているIPアドレスはリサイクルされるため、過去にブラックだったIPだとかなり厄介になることがあります。というのはDNSBLやWEBのブラックQUERYサービスの中にはネットワークブロックで設定しているケースが少なからずあるからだ。そうするとホワイトなIPアドレスでもブラック扱いにされてしまう可能性が十分にありえます。誤判定の多くは過去のIP悪さが起因するのもあるけれど、このようにネットワークマスクの縛りが原因でなってしまう場合もあります。IPアドレスのご判定は殆どが申請で取り消せるようになっていますがネットワークブロックで管理している場合は無理な時もあります。その意味でサーバを借りるときは必ずIPアドレスのチェックを行うことと、IPアドレスの再割り当てができるホスティングがベストです。

SPAM対策用のmain.cfの一部抜粋

reject_rbl_client が記述されているあたりがDNSBLのサーバエントリー。お付き合いしている会社により効きすぎたり、効かなすぎたりあるため使いながら外したりして調整を行う。

共有サーバは勘違い判定の巣窟になる。

共有サーバは１台のサーバに多数のサイトが運営されるサーバですが、このサイトの中に詐欺サイトやマルウェア感染原因のサイトがあるとどうなるかご存知でしょうか？プロバイダーが認識した場合はプロバイダーから改善通知や停止を言われますが、実際のところ運営者も気づいていないものもかなりあると思います。私も自分のお客様で幾つかこの様な例を経験しましたが、結論はGoogleやYahooの検索結果に出てこなくなりました。イメージ的にはGoogleのインデックスには残っているのでしょうが、一時的にマスクされているように思えます。ブラック発見は無料のbaraccudacntral.orgのサービスでチェックし、その後別のプライベートホスティングに移設しDNSを切り替えたところ５分で検索結果にTOP5で表示されるようになりました。この経験でGoogleが如何に様々な詐欺行為のサイトを抑え込むチェックを行ってるかがわかりました。ビジネスで本気勝負をかけて集客、販売する会社は共有サーバ使ってはいけませんね。

まっさらのLinuxに新規の場所へWEBのドキュメントルートを作りApacheを起動させると、よくエラーが生じることがあると思います。あるいはWORDPRESSのバージョンアップが出来ないとかフレームワークの更新ができないとか似たようなエラーを体験された方は多いのではないでしょうか。これは概ねお察しの通りSELinuxが有効になっているため起きているのですが、よくある処置はSElinuxをOFFにすることを勧めているケースが殆どです。しかし、SELinuxはセキュリティを高めるための仕組みですから有効のままで使いたいですよね！ということで、そのような場合の設定方法をご紹介いたします。

Apache HTTP Server が使うフォルダーを新規で設定する場合

デフォルトでは/var/www/htmlのみWEBフォルダーとして許可されているので任意の場所にドキュメントルートを設置するなら下記のように指定を行ってください。その後にApacheサーバを再起動すると動作する可能性が高いと思います。

今はGoogleのオールSSL化の推進によりかなりサイトがSSL接続仕様に変わってきた。しかし、実際のところそれで安心してはならない。SSLの設定のさじ加減というか塩梅によってはダメダメなケースもあるのです。その中でも一番肝と思うディレクティブ設定に以下のパラメータ設定がある。

暗号化通信の方式と暗号化アルゴリズムの選択

下記の設定はタイトルを表す通りの設定を行うApacheのディレクティブです。

• SSLProtocol
• SSLCipherSuite

脆弱性のある通信方式

SSLの通信方式には2014年10月に判明したSSL3.0およびTLS 1.0 / TLS 1.1の脆弱性があります。これを「POODLE」という名前で呼んでいます。 もともと、Googleの研究チームがSSLの解析を行い、2014年10月14日に、SSL3.0に関する脆弱性について重大なレポートを行ったのがきっかけです。POODLEは「POODLE(Padding Oracle On Downgraded Legacy Encryption)」の略称でSSL 3.0を有効にしているサーバに問題があると報告していましたが、その後TLS 1.0 / TLS 1.1の一部も問題ありと追加で報告されました。故にApacheでSSLを設定する際にデフォルトで設定していると脆弱性のある通信方式を許容するためセキュリティホールができてしまうのです。つまり、この対策は危険なプロトコルスィートを抑え込む設定が必要となります。

Apacheで行うべき設定

下記は、デフォルトではコメントアウトか、設定がないかもしれません。SSLのコンフィグ設定で追記して登録してください。危険ということで完全な抑え込みの設定をしてしまうと古いブラウザが対応できない場合があるためSSLProtocolの「-TLSV1」を入れるか、入れないかは正にさじ加減かなと思います。

設定後にテストを行う

設定ができたら評価をおこなってください。評価でA+取れるようにがんばってください。今はSNS等も評価がBレベルだとデベロッパーサイトでAPI登録を受け付けてくれないようになってきています。またGoogleもある一定期間の後にSSLの設定レベルの判別を明確にしてゆく話もありますので暗号化スィートの設定は非常に大事です。SEO的に大きな影響をもたらすので今後はApache要の設定となるでしょう。

SSLの設定レベルの品質評価

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

感染に気付けない恐怖

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

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

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

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

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

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

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

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