WordPressセキュリティ対策:Tableのリネーム

WordPress セキュリティ
WordPressのセキュリティに必要なこと
記事内に広告が含まれています。
PR広告

目的は、データベースに対するセキュリティ対策

目的は、データベース(db)テーブルに対するセキュリティ対策です。

Thank you for reading this post, don't forget to subscribe!
WordPress
WordPressのセキュリティに必要なこと

テーブルのリネームは、一連のセキュリティ対策の一環です。

WordPressをインストール後(デフォルト)では、全てのテーブルには「wp_」というプレフィックスが設定されています。

脆弱性対策の一環として「テーブル名」を特定されにくくし、データベースに対しての攻撃があった場合でも「テーブル名」が特定しずらく、攻撃者によって行われるSQLインジェクションで、不正にテーブルが削除・変更されてしまうなどの予防にも役立ちます

「テーブル名」を特定されにくくするために、プレフィックスをオリジナルに設定するのです。

 プレフィックスを変更できるプラグインも存在しますが、プラグインに頼るよりここではより確実なSQLによる変更を行います。

(SQL文など使い慣れていない方も多いかとはおもいますが、出来るだけ分かりやすくお伝えして行きますので、セキュリティ対策の一環としてお役立ていただければ幸いです。)

SQL Injection(インジェクション)は、アプリケーションのセキュリティ上の不備を意図的に利用し、アプリケーションが想定しないSQL文を実行させることにより、データベースシステムを不正に操作する攻撃方法

 (複数のSQL文を注入することによるデータの破壊やサイトコンテンツの改ざ、ストアドプロシージャ(データベースに対する一連の処理をまとめた手続きにしたもの)を実行されることによる情報の漏洩情報の改ざん、OSコマンドの実行などを引き起こすこともできる)

PR広告

手動でテーブル名を変更するセキュリティ対策

テーブルのリネーム
WordPressが使用するテーブル名の変更

正確にはWordPressが利用するデータベース(MySQL)のテーブルに対するprefix変更です。

導入時がベストですが、導入後でもできます。

一般的にはWordPressセットアップ直後がベストですが
WordPress
ホームページ公開後でも(対象が増えますので、少し手間が増えますが)できます

変更手順は、以下の3つのステップに分かれます。

①-「wp-config.php」で設定している、テーブルプレフィックス(prefix)を変更する

②- WordPressで利用している、全てのテーブルのプレフィックス(prefix)を変更する

③-「options」テーブルと「usermeta」テーブル内の項目を変更する

①「wp-config.php」で設定しているプレフィックスを変更

WordPressのファイル群で、テーブルプレフィックスを指定しているファイルが

wp-config.php」です。

今回WordPressインストールしたドメイン(イイネ.biz)にFTPで入って

WordPressフォルダ内の『wp-config.php』ファイル内で行います。

これをインストール時に設定してしまえば良いのですが、インストール後に変更したいという場合もあります。(この説明はWordPressインストール後の方法です。)

また、この記事では2つの環境(2つの異なるドメイン、 イイネ.biz: 当サイト と イイネ.net:テストサイト)に、ほぼ同時並行的にWordPressをインストールし、セキュリティ対策などを行っていくことで、タイミングの違いなどをそれぞれのキャプチャを添付し、出来るだけセキュリテイ対策をわかりやすくお伝えして行くことに努めています。

. 「wp-config.php」というファイルは、WordPressを利用する上で、最も重要で、最もセキュリティレベルを高く設定しなければいけないファイルです。

 なぜなら、「wp-config.php」には、データベースのアカウント情報(データベースのID・パスワード)が記載されているからです。

 リネーム後の「wp-config.phpそのもののセキュリティ対策後途(外部からのアクセスを不可にする為に、パーミッションも厳しく設定する。)でお伝えしたいと思います。

ここで、wp-config.phpを編集して、データベース(db)のテーブル名(プレフィックスだけ)を変更するだけでは、問題 (このままでは『このページにアクセスするための十分なアクセス権がありません。』と警告メッセージが表示されてしまいます。) が残ります。

 その為に、 wp-config.pnp内容自体(記述内容)を編集(変更)するのです。

wp-config.phpの中身の70行前後くらいにあ(利用環境によって前後します)

$table_prefix』という部分を変更・編集します。

$table_prefix = ‘wp_’; という部分を

$table_prefix = ‘wp2_’;  など、別なものに変更するのです。

.各自の実態にあわせて実際は別のプレフィックスにします。)

Point小文字/大文字の扱いは注意してください。

特に開発環境と運用環境が異なる場合は注意が必要です。

開発環境windowsMacで、運用環境Linux(多くのレンタルサーバー)の場合で、開発環境から運用環境にデプロイ(deploy:ネットワークを通じてシステムを開発環境から本番環境に配置)する様な場合、文字コードの関係で、開発環境で動いていたものが、運用(本番)環境では動かないなんてことにもなりかねません

(特にテーブル名など)※それぞれ文字コードの扱い(CCSID:文字セットの識別)が違いますから。(この件の詳しいことは別途日を改めてお伝えできれば、と思っています。)

またプレフックスの最後は半角アンダースコア( _ )で終わる様にしてください。

FTPで行う(XSERVERの場合)

Xserverログイン > ファイル監理 > FTP(WebFTP) > ご自分のドメイン名 > public_html >

 「✅」wp-config.php➡「編集」ボタン

wp-config.php の「編集」

wp-config.php の「編集」
wp-config.php の「編集」

✅ をつけて、「編集」ボタンを押下すると⇩以下の様な表示になります。

wp-config.php の「編集」
wp-config.php の「編集」

サーバーのFTP上での編集は困難ですので、コピペで「Sublime Text 3」などのテキストエディタに移して、「Sublime Text 3」上で編集後に、編集後の状態コピペWebFTP上移し保存する」で置き換えましょう。  wp-config.php

wp-config.php の「編集」
wp-config.php の「編集」

この例では72 Stepです。

ここを変更します。

wp-config.php
wp-config.phpの編集

⇧例では、72 Stepをコメント化し、新しく73Stepに追記したため、1Step増えました

この状態で、「Ctrl」+「A」で全体を選択しコピペでWebFTP上のwp-config.php

に移し「保存」します。

wp-config.php変更前
wp-config.php変更前

パス /xn--ecka7j.biz/public_html/   ⇩変更後、⇧変更前

wp-config.php変更後
wp-config.php変更後

更新日時が変わったことで更新を確認します。

続いて②データベース(db)の(全て(12個)のテーブルのプレフィックス)変更です。

phpMyAdminで行う

②利用している全テーブルのプレフィックスを変更する

XSERVERログイン>サーバ管理>データベース>phpmyadmin(MySQL5.7)

 php-adminログイン

php-adminログイン
php-adminログイン
この時点のテーブル一覧
この時点のテーブル一覧(12テーブル)

「SQL」タブに移ります。

「SQL」タブ
「SQL」タブ

 既に、同じデータベース上に、別のドメイン用のWordPressをインストールし、プレフィックスも変更していることから、ここでは別のプレフィックス(ユニーク・一意)を付けます。

「SQL」タブから、ALTER TABLE wp_commentmeta RENAME TO jn1_commentmeta; などを入力して変更します。「実行」

 しかし、SQLタブに直接入力は間違えやすく・しかも困難な部分もあります

 事前にテキストエディタでしっかり文法ミスの無い様に入力してチェックしておいてから、

コピペでSQLタブに移して「実行」の方が良いでしょう。

ALTER TABLE実行後
ALTER TABLE実行 前

と言っておいて実際にはミスるのですが(笑)・・・印をつけたもの。この時点ではまだ気付いていない

あなたに、間違い(違い)が分かりますか?

ALTER TABLE
ALTER TABLE

ここで実行

実行後のメッセージ
実行後のメッセージ

 でエラーが無かったことが判ります。

「F5」キーでリフレッシュ表示すると、

12個のテーブル名のリネーム(プレフィックスの変更)完了が確認できます。

結果
ここで気づいても良いのですが、、、

「構造」をクリックすると ⇩

テーブルの並び順が
テーブルの並び順が!!!

 ☝テーブルの並び順がおかしい?(ここでやっと気付く)

 リネームミスですjnl_postmeta は、jn1_postmeta に修正です。

見分けがつきにくい1とl
修正後
修正後

OKです。

これで、Wordpress標準で設定されているテーブルは全てプレフィックスを変更しました。

ですが、注意しなければならないのが「プラグイン」で使用しているテーブルもプレフィックス変更しなければならない。ということです。

今回の場合は、WordPressをインストールしただけで、何もプラグインをインストールしていないから大丈夫です。

ここで、各テーブルのプレフィックスが前の例と違うのはご愛敬

(単にこのタイミング(プラグインの導入でテーブルが)14個のになった時のキャプチャを忘れたので、別の環境のものを貼り付けています)

ほかのデータベースのテーブルのキャプチャですm( _ _ )m

別環境のリネーム状況
別環境のリネーム状況: : SiteGuard WP Pluginで2つ追加

例えば、 別環境だと2つテーブルが多く14個です。

(SiteGuard WP Pluginで追加されたものです。:日本製のサイトガード用のプラグイン)

更に、プラグインの「xo security」をインストールすると、(☚セキュリティプラグイン)

**_xo_security_loginlogテーブルが追加され15Tableとなっています

「xo security」をインストール
「xo security」をインストールでテーブルが1つ追加された 

☝は別環境、①②③の処理(プレフィックス変更)後にプラグインをインストールで追加されたテーブルですが、の『wp-config.php』の変更と、テーブル内の項目を変更の結果がうまく反映されていることの表れ(証明)です。

次は③テーブル内の項目を変更です。

③「options」・「usermeta」テーブル内の項目を変更する

 先ほど、Wordpressで利用している全テーブルのプレフィックスを変更しましたが、このままだと、まだ不十分です。

試しに、WordPressの管理画面を開いてみますと、「アクセス権限がありません」とエラーになります。まだやらなければならない作業があるからです。

理由は、「wp_」というプレフィックスが使用されているのは、テーブル名だけでなくデータの名前にも使用されているからです。

 どこのデータかというと、オリジナルのテーブルでは、『wp_options』と『wp_usermeta』で、あなたが先の処理で変更した。

jn1_optionsテーブルと「jn1_usermetaテーブル内にあるデータです。

 テーブル名は、分かりました。でもどうやってテーブル内のデータを見つけるの?

お任せください。

まず、「options」テーブル内から、下記クエリで、該当データを検索しましょう。

SELECT * FROM jn1_options WHERE option_name LIKE ‘%wp_%

テーブルjn1_optionsoption_nameと言う項目の中(データ)にLIKE %wp_%’ は総称名(ワイルドカード:wp_で始まるもの全て)で探す(SELECTする)ことを指示しています。

SELECT文
SELECT文
SQLタブでSELECT文を実行
SQLタブでSELECT文を実行

「実行」すると、

実行結果
実行結果

となります。対象は、 WP_user_rolesです 。

wp_user_roles
wp_user_roles

.ここで、 id:91の wp_page_for_privacy_policy もWP_が付いているじゃあないかとお気づきのあなた、「さすが、注意力があります」。でも安心してください。

wp_page_for_privacy_policy
wp_page_for_privacy_policy

wp_page_for_privacy_policyには他に影響を与えるデータではないのです。

(プライバシーポリシーに関するものです)

⇧ここで「✅」「編集」クリックでここの値を直接編集入力で「jn1_user_roles」に変更して「実行」でも良いのですが、確実性を求め、SQLで実行します。

UPDATE文
UPDATE文
UPDATE文
UPDATE文

「実行」

確認
確認
確認
確認

「実行」

変更を「確認」
変更を「確認」

同様に、確認

「SQL」から、確認2
確認2
「SQL」から、確認2
「SQL」から、確認2
結果
結果

同様に、更新

同様に、更新
同様に、更新
同様に、「SQL」から、更新
同様に、「SQL」から、更新

「更新」

ん!
ん! 2行変更されているハズ?なのに、確認します。

 ⇧2行変更されているハズなのに、確認します。 ‘wp_が残っていないか

wp_が残っていないか?
wp_が残っていないか?
wp_が残っていないか?
wp_が残っていないか?

「実行」

☝2件だけで、先の2件は’wp_’でない結果(抽出されない)
☝2件だけで、先の2件は’wp_’でない結果(抽出されない)

  ☝2件だけで、先の2件はwp_でない結果(抽出されない)となっている。

「再確認:「1行変更しました。」とは?

再確認
再確認
再確認
再確認

実行

再確認 結果OK
再確認 2件ともmeta_key更新されている結果OK

2件ともmeta_key更新されている結果OK

phpMyAdminのバグ?
phpMyAdminのバグ?

2件とも更新されているしOK・・・・メッセージだけphpMyAdminのバグ?

これで、データベース(db)aitc_wp2の全テーブルのプレフィックスの変更は終わりです。

長文にお付き合いいただきありがとうございました。

ちょっと待った~~~~~

 最初に、

脆弱性対策の一環として「テーブル名」を特定されにくくし、データベースに対しての攻撃があった場合でも「テーブル名」が特定し辛く、攻撃者がSQLインジェクションで、不正にテーブルが削除・変更されてしまうなどの予防にも役立ちます。

「テーブル名」を特定されにくくするために、プレフィックスをオリジナルに設定するのです。』

と言っていながら、テーブルのプレフックス名も、中身の設定値もマスキングすることなく全て開放して大丈夫かよ? 

 この様な設定方法はネットで他にもみかけるが、みんな肝心な部分はマスクしているぞ!

キュリティ対策が大事とかいって大丈夫かよ?

大丈夫です。

 マスキングすると肝心なところが隠れてしまい、あなたに伝えにくくなるから、あえてマスキングしていないのです。

(分かりやすく伝えることがこのブログの目的です。隠すべきところは、隠していますから。ブログを公開する前に、それでも尚あなたが脆弱性を見つけたら、連絡いただけると嬉しいです。)

そして、ここをお見せしても大丈夫と言える根拠が、次にお伝えする

wp-config.phpをアクセス不可に設定する」と、その次の「パーミッションの変更」です。

情報セキュリティ
情報セキュリティ

「wp-config.php」そのもののセキュリティ対策(外部からのアクセスを不可に設定し、パーミッションも厳しく設定する。

「wp-config.php」アクセス不可に設定する

WebFTP (XSERVER)で行う

.htaccess
「wp-config.php」と同じ階層にある「.htaccess」ファイルを編集

外部からアクセスされないように.htaccessを使って制限を掛ける

.htaccessを使って制限 する

<Files wp-config\.php>

Order deny,allow

Deny from all

</Files>

#  \は、Linuxでは半角のバックスラッシュ(筆者の環境はWindowsなので )

 これが無い記述を他のサイト3か所で見かけるますが・・・がある方が正しい様です。

これで実際wp-config.phpファイルにアクセスすると403エラーが返るはずです。

これで、外部からのアクセスは不可能になります。

攻撃されやすいファイルのアクセス制限

wp-config.php :WordPressの動作に必要な設定ファイル と並んで攻撃されやすい

  • wp-cron.php :予約投稿やアップデート通知など時刻連動の処理に使われるファイル

.htaccessを使ってwp-config.phpと同様に制限を掛けるのが良いでしょう。

.htaccessに記載( wp-config.php  と wp-cron.php  )

wp-cron.php
Windows上

\は、サーバ上(Linux上)では、半角のバックスラッシュです。Windows上では表現が難しいため。以下に画像で表示します。

(サーバ上の.htaccessへは、上記のものをコピペで、# BEGIN WordPressの上の行に挿入貼り付けしてください。)

こちらが画像
Linuxサーバ上こちらが画像wp-config.php と• wp-cron.php

.htaccessの保護

.htaccess自体が不正アクセスされては他の設定も無意味になってしまうので.htaccessファイルそのものへのアクセスをすべて拒絶します。

(分散設定ファイル ドット・エイチ・ティ・アクセス Apacheを用いたWebサーバにおいて、ディレクトリ単位で設置及び設定(サーバの挙動を決定する設定ファイルのひとつ)を行える設定ファイル)

.htaccess 自体の保護

.htaccessファイルそのものへのアクセスをすべて拒絶
.htaccessファイルそのものへのアクセスをすべて拒絶

ディレクトリ表示の禁止

 ブラウザでディレクトリにアクセスされた時にファイル一覧が見られる状態は攻撃の手がかりになってしまうため、表示されないようにします。

index.htmlindex.phpが存在しないディレクトリに対してブラウザからアクセスすると、そのディレクトリにあるファイルの一覧が表示される場合があります。

 表示されているファイルによっては、不正なアクセスに利用されてしまうかもしれませんので、ファイルの一覧を非表示にしておきましょう。

.htaccessに記述を追加する

.htaccessに記述を追加するのですが、WordPressが動作しているサーバによって設定方法が異なります。()

設定方法1

XSERVER
XSERVER

設定方法2(さくらインターネットなどのレンタルサーバでは、Optionsは利用できません

DirectoryIndex index.html .ht

とか

さくらインターネットなどのレンタルサ
さくらインターネットなどのレンタルサ

DirectoryIndex index.html index.htm index.php index.cgi .ht

DirectoryIndex、サイト訪問者がディレクトリをリクエストしたときに調べるリソースのリストを設定する記述です。

ディレクトリへのアクセスがあった場合index.html → index.htm → index.php → index.cgiとファイルをたどっていき、無い場合は「.ht」となり、403を返します。

Point

サーバでOptionsが使えるかどうかわからない場合は、まずはOptionsを利用した方法を試してみてください。それでうまく制限できなかった場合はDirectoryIndexの記述方法を試してみてください。

注意

.htaccessファイルに既に何か書き込まれている場合は、絶対に変更しないでください。書き加えるのみです。

何か書き込まれている場合は、.htaccessファイルの最後尾に以下のように追記するだけです。

.htaccessファイルの最後尾に以下のように追記
.htaccessファイルの最後尾に以下のように追記 今回は、XSERVERのWebFTPで直接編集しています。

注意

.htaccessファイルは編集を誤ると、重大なエラーを引き起こす設定サーバ用のファイルです。編集を行う前は事前にファイルをコピーしてバックアップを取っておいてください。何か不具合が出た場合はそのファイルから復元してください。

https://xn--ecka7j.net/wp-content/uploads/ でアクセスしてみると、

403
403アクセス認可なし・・・これはXSERVERの表現です

ログイン管理画面(wp-login.php)のアクセス制限

別途(SiteGuard WP Plugin)で行う

ログイン画面への攻撃を防ぐため、関係者以外はログイン画面にアクセスできないようにします。

➡ これは、次に別途)お伝えするプラグイン(SiteGuard WP Plugin)で行いSiteGuard WP Pluginます。

(関係者以外はログイン画面にアクセスできないようにするため、wp-login.phpのファイル名そのものを隠蔽してしまいます。)

次は、パーミッション設定です。

WebFTPで行う(XSERVER)

security
security

wp-config.phpのパーミッション

wp-config.php」のパーミッションは「400」が推奨ですが、・・・

ただし、共有サーバの場合「400」で設定できないケースも多いようで、WordPress.org では「600」を推奨しています。

当ブログで利用しているホスティング会社のXSERVERも「600」を推奨しているため、その設定で運用しています。

XSERVERの場合は「600所有者 書き込み権限+読み込み権限

200 所有者 書き込み権限
400 所有者 読み込み権限
数字 意味
「600」所有者 書き込み権限+読み込み権限
「パーミッション変更」で可能の様ですが、

「パーミッション変更」で可能の様ですが、このまま推奨値「600」で行きます。

 「wp-config.php」以外のパーミッションの設定は、また別の機会に。

.htaccess のパーミッション

「604」(所有者 書き込み・読み取り /その他 読み込み権限)か「606」

「.htaccess」ファイルが書き換えられる事例が多発しており、パーミッション設定は必須です。パーマリンク(Webページ毎に設定した(カテゴリ構造の)URL)の設定が出来るようにするには「606」(所有者 書き込み・読み取り /その他 書き込み・読み込み)にします。

.htaccess
.htaccess

「644」は(所有者 書き込み・読み取り /グループ 読み込み権限/その他 読み込み権限)

 ここは➡「604」に変更・更新

 ちなみに、XSERVERでの推奨値は以下の様になっています。

パーミッションの設定について
パーミッションの設定について

‘wp-config.phpの省略値が600であったのは、グループにも一般ユーザにも、厳しい設定の様です。(読むこともできない設定)

次は、セキュリティ対策用のプラグインのインストール・設定・有効化です。

PingBack機能を悪用したDDoS攻撃の防止のためにもプラグインでPingBackを無効化します。

使用するプラグインは、SiteGuard WP Pluginです。

まとめ

データベーステーブルのセキュリティ対策のみに留まらず、.htaccessやパーミッションの設定の一部まで、踏み込んでしまいました。

.htaccessやパーミッションの設定 については別記事にしても良いのかもしれませんが、ここデータベース・テーブルでのセキュリティ対策と密接な関係があり、離して書いてしまうと、テーブルのセキュリティ対策が不充分・不備となります。

また、 .htaccessやパーミッションの設定 を別記事にしたところでデータベース・テーブルに対する .htaccess記述やパーミッションの設定が出てきますので、やはりここで書くべきだと判断した次第です。

長文になってしまいました。

ここまで読んでくださってありがとうございます。

コメント

タイトルとURLをコピーしました