目的は、データベースに対するセキュリティ対策
目的は、データベース(db)テーブルに対するセキュリティ対策です。
Thank you for reading this post, don't forget to subscribe!
テーブルのリネームは、一連のセキュリティ対策の一環です。
WordPressをインストール後（デフォルト）では、全てのテーブルには「wp_」というプレフィックスが設定されています。
脆弱性対策の一環として「テーブル名」を特定されにくくし、データベースに対しての攻撃があった場合でも「テーブル名」が特定しずらく、攻撃者によって行われるSQLインジェクション※で、不正にテーブルが削除・変更されてしまうなどの予防にも役立ちます。
「テーブル名」を特定されにくくするために、プレフィックスをオリジナルに設定するのです。
プレフィックスを変更できるプラグインも存在しますが、プラグインに頼るよりここではより確実なSQLによる変更を行います。
（SQL文など使い慣れていない方も多いかとはおもいますが、出来るだけ分かりやすくお伝えして行きますので、セキュリティ対策の一環としてお役立ていただければ幸いです。）
※．SQL Injection（インジェクション）は、アプリケーションのセキュリティ上の不備を意図的に利用し、アプリケーションが想定しないSQL文を実行させることにより、データベースシステムを不正に操作する攻撃方法。
（複数のSQL文を注入することによるデータの破壊やサイトコンテンツの改ざん、ストアドプロシージャ(データベースに対する一連の処理をまとめた手続きにしたもの)を実行されることによる情報の漏洩や情報の改ざん、OSコマンドの実行などを引き起こすこともできる）
手動でテーブル名を変更するセキュリティ対策
正確にはWordPressが利用するデータベース（MySQL）のテーブルに対するprefix変更です。
導入時がベストですが、導入後でもできます。
一般的にはWordPressセットアップ直後がベストですが、
WordPress
ホームページ公開後でも（対象が増えますので、少し手間が増えますが）できます。
変更手順は、以下の３つのステップに分かれます。
①-「wp-config.php」で設定している、テーブルプレフィックス（prefix）を変更する
②- WordPressで利用している、全てのテーブルのプレフィックス（prefix）を変更する
③-「options」テーブルと「usermeta」テーブル内の項目を変更する
①「wp-config.php」で設定しているプレフィックスを変更
WordPressのファイル群で、テーブルプレフィックスを指定しているファイルが
「wp-config.php」です。
今回WordPressをインストールしたドメイン（イイネ.biz）にFTPで入って、
WordPressフォルダ内の『wp-config.php※』ファイル内で行います。
これをインストール時に設定してしまえば良いのですが、インストール後に変更したいという場合もあります。（この説明はWordPressインストール後の方法です。）
また、この記事では２つの環境（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： ※. 小文字／大文字の扱いは注意してください。
特に開発環境と運用環境が異なる場合は注意が必要です。
開発環境がwindowsやMacで、運用環境がLinux（多くのレンタルサーバー）の場合で、開発環境から運用環境にデプロイ(deploy：ネットワークを通じてシステムを開発環境から本番環境に配置)する様な場合、文字コードの関係で、開発環境で動いていたものが、運用（本番）環境では動かないなんてことにもなりかねません
（特にテーブル名など）※それぞれ文字コードの扱い(CCSID:文字セットの識別)が違いますから。（この件の詳しいことは別途日を改めてお伝えできれば、と思っています。）
またプレフックスの最後は半角アンダースコア( _ )で終わる様にしてください。
FTPで行う（XSERVERの場合）
Xserverログイン ＞ ファイル監理 ＞ FTP(WebFTP) ＞ ご自分のドメイン名 ＞ public_html ＞
「✅」wp-config.php➡「編集」ボタン
wp-config.php の「編集」
✅ をつけて、「編集」ボタンを押下すると⇩以下の様な表示になります。
サーバーのFTP上での編集は困難ですので、コピペで「Sublime Text 3」などのテキストエディタに移して、「Sublime Text 3」上で編集後に、編集後の状態をコピペでWebFTP上に移し「保存する」で置き換えましょう。 wp-config.php
この例では、72 Stepです。
ここを変更します。
⇧例では、72 Stepをコメント化し、新しく73Stepに追記したため、１Step増えました
この状態で、「Ctrl」＋「A」で全体を選択しコピペでWebFTP上のwp-config.php
に移し「保存」します。
パス /xn--ecka7j.biz/public_html/ ⇩変更後、⇧変更前
更新日時が変わったことで更新を確認します。
続いて②データベース(db)の(全て（12個）のテーブルのプレフィックスを)変更です。
phpMyAdminで行う
②利用している全テーブルのプレフィックスを変更する
XSERVERログイン＞サーバ管理＞データベース＞phpmyadmin(MySQL5.7)
php-adminログイン
「SQL」タブに移ります。
既に、同じデータベース上に、別のドメイン用のWordPressをインストールし、プレフィックスも変更していることから、ここでは別のプレフィックス（ユニーク・一意な）を付けます。
「SQL」タブから、ALTER TABLE wp_commentmeta RENAME TO jn1_commentmeta; などを入力して変更します。「実行」
しかし、SQLタブに直接入力は間違えやすく・しかも困難な部分もあります。
事前にテキストエディタでしっかり文法ミスの無い様に入力してチェックしておいてから、
コピペでSQLタブに移して「実行」の方が良いでしょう。
と言っておいて実際にはミスるのですが（笑）･･･印をつけたもの。この時点ではまだ気付いていない
あなたに、間違い（違い）が分かりますか？
ここで実行
でエラーが無かったことが判ります。
「F5」キーでリフレッシュ表示すると、
12個のテーブル名のリネーム（プレフィックスの変更）完了が確認できます。
「構造」をクリックすると ⇩
☝テーブルの並び順がおかしい？（ここでやっと気付く）
リネームミスですjnl_postmeta は、jn1_postmeta に修正です。
⇧OKです。
これで、Wordpress標準で設定されているテーブルは全てプレフィックスを変更しました。
ですが、注意しなければならないのが、「プラグイン」で使用しているテーブルもプレフィックス変更しなければならない。ということです。
今回の場合は、WordPressをインストールしただけで、何もプラグインをインストールしていないから大丈夫です。
ここで、各テーブルのプレフィックスが前の例と違うのはご愛敬
（単にこのタイミング(プラグインの導入でテーブルが)14個のになった時のキャプチャを忘れたので、別の環境のものを貼り付けています）
ほかのデータベースのテーブルのキャプチャですm( _ _ )m）
例えば、⇧ 別環境※だと2つテーブルが多く14個です。
(SiteGuard WP Pluginで追加されたものです。：日本製のサイトガード用のプラグイン)
更に、プラグインの「xo security」をインストールすると、（☚セキュリティプラグイン）
**_xo_security_loginlogテーブルが追加され15Tableとなっています⇩
☝は別環境、①②③の処理(プレフィックス変更)後にプラグインをインストールで追加されたテーブルですが、①の『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_optionsのoption_nameと言う項目の中(データ）にLIKE %wp_%’ は総称名（ワイルドカード：wp_で始まるもの全て）で探す（SELECTする）ことを指示しています。
「実行」すると、
となります。対象は、 WP_user_rolesです 。
※．ここで、 id：91の wp_page_for_privacy_policy もWP_が付いているじゃあないかとお気づきのあなた、「さすが、注意力があります」。でも安心してください。
’wp_page_for_privacy_policyには他に影響を与えるデータではないのです。
（プライバシーポリシーに関するものです）
⇧ここで「✅」「編集」クリックでここの値を直接編集入力で「jn1_user_roles」に変更して「実行」でも良いのですが、確実性を求め、SQLで実行します。
「実行」
「実行」
同様に、更新
「更新」
⇧2行変更されているハズ？なのに、確認します。 ‘wp_が残っていないか？
「実行」
☝2件だけで、先の2件は’wp_’でない結果(抽出されない)となっている。
「再確認：「１行変更しました。」とは？」
実行
2件ともmeta_key更新されている結果OK
２件とも更新されているしOK・・・・メッセージだけphpMyAdminのバグ？
これで、データベース(db)aitc_wp2の全テーブルのプレフィックスの変更は終わりです。
長文にお付き合いいただきありがとうございました。
ちょっと待った～～～～～
最初に、
『脆弱性対策の一環として「テーブル名」を特定されにくくし、データベースに対しての攻撃があった場合でも「テーブル名」が特定し辛く、攻撃者がSQLインジェクション※で、不正にテーブルが削除・変更されてしまうなどの予防にも役立ちます。
「テーブル名」を特定されにくくするために、プレフィックスをオリジナルに設定するのです。』
と言っていながら、テーブルのプレフックス名も、中身の設定値もマスキングすることなく全て開放して大丈夫かよ？
この様な設定方法はネットで他にもみかけるが、みんな肝心な部分はマスクしているぞ！
セキュリティ対策が大事とかいって大丈夫かよ？
大丈夫です。
マスキングすると肝心なところが隠れてしまい、あなたに伝えにくくなるから、あえてマスキングしていないのです。
（分かりやすく伝えることがこのブログの目的です。隠すべきところは、隠していますから。ブログを公開する前に、それでも尚あなたが脆弱性を見つけたら、連絡いただけると嬉しいです。）
そして、ここをお見せしても大丈夫と言える根拠が、次にお伝えする
「wp-config.phpをアクセス不可に設定する」と、その次の「パーミッションの変更」です。
「wp-config.php」そのもののセキュリティ対策（外部からのアクセスを不可に設定し、パーミッションも厳しく設定する。）
「wp-config.php」アクセス不可に設定する
WebFTP (XSERVER)で行う
「wp-config.php」というファイルは、Wordpressを利用する上で、最も重要で、最もセキュリティレベルを高く設定しなければいけないファイルです。
大事なのは「外部からのアクセスを不可に設定し、パーミッションも厳しく設定する」事です。
以下の手順で行います。
まず、「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 ）
\は、サーバ上(Linux上)では、半角のバックスラッシュです。Windows上では表現が難しいため。以下に画像で表示します。
（サーバ上の.htaccessへは、上記のものをコピペで、# BEGIN WordPressの上の行に挿入貼り付けしてください。）
.htaccessの保護
.htaccess自体が不正アクセスされては他の設定も無意味になってしまうので.htaccessファイルそのものへのアクセスをすべて拒絶します。
（分散設定ファイル ドット・エイチ・ティ・アクセス Apacheを用いたWebサーバにおいて、ディレクトリ単位で設置及び設定（サーバの挙動を決定する設定ファイルのひとつ）を行える設定ファイル）
.htaccess 自体の保護
ディレクトリ表示の禁止
ブラウザでディレクトリにアクセスされた時にファイル一覧が見られる状態は攻撃の手がかりになってしまうため、表示されないようにします。
index.htmlやindex.phpが存在しないディレクトリに対してブラウザからアクセスすると、そのディレクトリにあるファイルの一覧が表示される場合があります。
表示されているファイルによっては、不正なアクセスに利用されてしまうかもしれませんので、ファイルの一覧を非表示にしておきましょう。
.htaccessに記述を追加する
.htaccessに記述を追加するのですが、WordPressが動作しているサーバによって設定方法が異なります。（）
設定方法1
設定方法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ファイルは編集を誤ると、重大なエラーを引き起こす設定サーバ用のファイルです。編集を行う前は事前にファイルをコピーしてバックアップを取っておいてください。何か不具合が出た場合はそのファイルから復元してください。
https://xn--ecka7j.net/wp-content/uploads/ でアクセスしてみると、
ログイン管理画面（wp-login.php）のアクセス制限
別途（SiteGuard WP Plugin）で行う
ログイン画面への攻撃を防ぐため、関係者以外はログイン画面にアクセスできないようにします。
➡ これは、次に（別途）お伝えするプラグイン（SiteGuard WP Plugin）で行い
ます。
（関係者以外はログイン画面にアクセスできないようにするため、wp-login.phpのファイル名そのものを隠蔽してしまいます。）
次は、パーミッション設定です。
WebFTPで行う（XSERVER）
wp-config.phpのパーミッション
「wp-config.php」のパーミッションは「400」が推奨ですが、・・・
ただし、共有サーバの場合「400」で設定できないケースも多いようで、WordPress.org では「600」を推奨しています。
当ブログで利用しているホスティング会社のXSERVERも「600」を推奨しているため、その設定で運用しています。
XSERVERの場合は「600」所有者 書き込み権限+読み込み権限
| 200 | 所有者 書き込み権限 |
| 400 | 所有者 読み込み権限 |
| 数字 | 意味 |
「パーミッション変更」で可能の様ですが、このまま推奨値「600」で行きます。
「wp-config.php」以外のパーミッションの設定は、また別の機会に。
.htaccess のパーミッション
「604」(所有者 書き込み・読み取り ／その他 読み込み権限)か「606」
「.htaccess」ファイルが書き換えられる事例が多発しており、パーミッション設定は必須です。パーマリンク(Webページ毎に設定した(カテゴリ構造の)URL)の設定が出来るようにするには「606」(所有者 書き込み・読み取り ／その他 書き込み・読み込み)にします。
「644」は(所有者 書き込み・読み取り ／グループ 読み込み権限／その他 読み込み権限)
ここは➡「604」に変更・更新
ちなみに、XSERVERでの推奨値は以下の様になっています。
‘wp-config.phpの省略値が600であったのは、グループにも一般ユーザにも、厳しい設定の様です。（読むこともできない設定）
次は、セキュリティ対策用のプラグインのインストール・設定・有効化です。
PingBack※機能を悪用したDDoS攻撃の防止のためにもプラグインでPingBackを無効化します。
使用するプラグインは、SiteGuard WP Pluginです。
まとめ
データベーステーブルのセキュリティ対策のみに留まらず、.htaccessやパーミッションの設定の一部まで、踏み込んでしまいました。
.htaccessやパーミッションの設定 については別記事にしても良いのかもしれませんが、ここデータベース・テーブルでのセキュリティ対策と密接な関係があり、離して書いてしまうと、テーブルのセキュリティ対策が不充分・不備となります。
また、 .htaccessやパーミッションの設定 を別記事にしたところでデータベース・テーブルに対する .htaccess記述やパーミッションの設定が出てきますので、やはりここで書くべきだと判断した次第です。
長文になってしまいました。
ここまで読んでくださってありがとうございます。
コメント