【対策 その2】 脆弱性を潰していった

前のページ【ショック】セキュリティ警告&ハッキング被害を発見した)でも書いたように、うちのサイトやブログのドメインには、悪意のある何者かによってフィッシングマルウェアのファイルが設置されてしまいました。

ですので、もうすでに恐らくうちのサイトやブログのドメインは、悪意のあるハッカーたちの 『 脆弱性のあるまま放置されていたURLリスト 』 の中に入っているのではないかと思っています。

ですので、うちのWEBサイトやブログに脆弱性が残ったままだと、まだハッキング被害に合っていないWEBサイトやブログよりも、ハッキング餌食になる可能性が高くなるのではないかと思います。

ですので、漏れのないようにサイトやブログの脆弱性を潰す、それも緊急に潰す必要がありました。

潰したブログの脆弱性

  • コメント欄を閉鎖
  • WAFをONにする
  • プラグインでテンプレート・プラグイン・WPデータを最新になるように設定
  • ブログのテンプレートを公式テーマにする
  • プラグインを出来るだけ削除する

Wordpress のプラグインは様々な種類があり、その多くが便利なものなのですが、何せオープンソースなものですから、セキュリティの脆弱性が発見されやすく、攻撃対象になりやすいのが難点です。
(公式にUPしたばかりのものですと、セキュリティの脆弱性がないものが多いのですが)

Wordpress本体のプログラムは、監視の目が行き届きやすいため脆弱性の目が摘まれやすいのですが、Wordpress で使用できる各プラグイン脆弱性の発見が遅れかなりの被害者が出てから発見されるケースや、データベースの書き換えなどの深刻な問題が発生してから発見されるケースもあるため(問題が特定できないまま放置されるケースもある)、実は使用には注意が必要だったりします。

この他、Wordpressのプラグインには放置されたものも多く存在します。
新規プラグインのインストール機能を使ってダウンロードする場合には、問題が発見されたプラグインはインストールできなくなっているので問題が起こりにくいのですが、古いプラグインずっと入れっぱなしの場合、入れた本人には問題があるプラグインかどうかはわからりにくいのも難点です。

使用に問題がないかどうか、公式サイトなどを定期的に確認すれば良いのはわかるのですが、確認が面倒で放置してしまっている場合、脆弱性を突かれてハッキングを許してしまう可能性もあります。

そこで、できるだけプラグインを使わずに、テンプレートを改造したり自作のテンプレートを使用して function.php にコードを直書きして対処しようとすると、これがまた、セキュリティの脆弱性の温床になる場合もあるので、困り者だったりします。

自分の場合、どこが問題だったのか最後まで不明だったため、結局わからずじまいだったのですが、もしかしたら、自作テンプレート古いプラグインにも問題があったのではないかと思うこともあります。
(『 コメント欄に悪意のあるコードを書き込まれた → askimet で非表示 → データが汚染 → ハッカーにより悪意のあるコードを設置 』 の可能性も高いとは思うのですが・・・)


WEBサイトのテンプレートの脆弱性を潰す

WEBサイトは、メンテナンスを考慮してテンプレートをphpで読み込む形にしてあるのですが、そこで $_SERVER['HTTP_HOST']や$_SERVER['SERVER_NAME'] を使っていたのは問題があるようでした。
(Hostヘッダインジェクションによる攻撃が可能になる場合があるらしい)


【脆弱性対応備忘録】脆弱性の種類とチェック・リストアップと簡単な対応例 - Qiita

PHPにおけるHostヘッダインジェクション攻撃が可能な脆弱性


その他、シングルクォーテーションはあまりよろしくないと言うことで、ファイルを includeするコードをシングルクォーテーション 『 ' 』 からダブルクォーテーション 『 " 』 に変更しました。


/wp-admin/ に .htaccess を設置

Wordpress のコアファイルの入っている 『 wp-admin フォルダ 』 自分のIPかヘテムルFTPでないとアクセスできないように設定しました。

ヘテムルは、自分のIPとヘテムルFTPを許可し、その他のIPからのアクセスを一切禁止するftpaccess ファイル用のコードを自動で表示してくれるので、それを使用しました。
(頻繁に使用中のIPアドレスが変更される場合、ヘテムルのこの機能はとても便利です)

ただ、これをやってしまったことで、Jetpack が正常に機能しなくなってしまいました。
(それについては、Wordpress連携ができなくなってしまった!ページに詳しく書きました)

wp-login.php については、もうすでに自分のIPかヘテムルFTPでないとアクセスできないように htaccessファイルで設定してあったので、今回は変更なしでした。


新しいセキュリティ用のプラグインを2種類ほど入れた

テンプレートファイルコアファイル、データベースのプレフィックス名の問題指摘してもらえるプラグインと、コアファイルの改変チェックログイン履歴の保存マルウェア汚染の有無をチェックする高機能なプラグインの2種類のセキュリティ用のプラグインを導入しました。

コアファイルの属性のチェックです。
何気に wp-config.php提案されている属性が書き換え可能な 0644 になっている辺りが 『あれ? ( ゚艸゚; ) 』 と言う感じです。
ヘテムルでは 400 にしないと注意されてしまうので)

データベースプレフィックスは、そのまんま普通にWorpdess をインストールすると、『 wp_ 』 のままになっています。

これをそのままにしてしまうと脆弱性を突かれやすくなってしまうため、ここは変更しておいたほうが良いようです。

でも、データベースを直弄りする作業が入ってくるので、自分でやるのはかなりしんどいです。
でも、このプラグインを使うと、Change the current: の欄の中に変更したいプレフィックス名を入れるだけで、簡単にプレフィックス名を変更できるので非常に便利です。

ただし、その場合は wp-config.php の属性を writable(書き換え可能)にする必要があります。
(『 wp-config.php ファイル書き換え可能にしなければならない 』 と言うエラーメッセージが出てますね。(;´∀`))



この書き換え作業は速攻で終わりますので、作業前にちょっとだけ wp-config.php書き換え可能な属性(644など)にしておき、作業終了直後に 400 に戻すと良いです。



後は、設定項目に全部チェックを入れてと。
そうすれば、全てのセキュリティの項目で良い状態になります。


ただしこれ、このプラグインをアンインストールすると、せっかく設定した項目全部元に戻ってしまうため、アンインストールできないのが難点です。
(テーブルプレフィックスや属性の変更など、処理されたものはそのまま残ります)

アンインストール出来ない場合、このプラグインが更新停止されてしまった場合、このプラグイン自身が脆弱性の温床と化してしまう可能性があるため、自分で設定項目が『 良 』 の状態なるよう、Wordpess を設定しないといけないです。
(私はその作業がめんどくさすぎて結局やりませんでした。ヽ(´Д`;)ノ)


広告