WordPress サイトの MySQL を強化する

公開: 2023-01-18

最も人気のある CMS である WordPress は、最も人気のあるデータベースである MySQL で実行されます。 MySQL のインストールと WordPress データベース構成のインストールが一般的な攻撃ベクトルに対して適切に強化されていることを確認するために時間を費やすことは、リスクを軽減するのに役立ちます。 これは、MySQL サーバーを自分で管理している場合に特に当てはまります。

多くの WordPress インストールでは、MySQL のフォークである MariaDB が使用されていることに注意してください。 どちらも非常によく似た働きをするため、MySQL は MySQL と MariaDB の両方を意味します。 実行している RDMS フレーバーに関係なく、MySQL を強化すると、ハッカーからの攻撃のリスクを最小限に抑えることができます。 ただし、これは、Web アプリケーション ファイアウォールのインストール、プラグイン、テーマ、WordPress の最新バージョンの確保、WordPress の強化など、他のセキュリティ対策に取って代わるものではありません。

注意してください、この記事は Linux (Ubuntu) で動作する MySQL 8.0 を対象としています。 概念は他のオペレーティング システムや MySQL/MariaDB バージョンにも適用されますが、これらの例で使用されているコマンドとファイル パスは異なる場合があります。 本番システムに変更を加える前に、ステージング環境または本番前環境で変更をテストすることを強くお勧めします。

この記事では、独自の MYSQL を管理する人を主な対象としており、MySQL を保護する方法に関するいくつかのヒントとチュートリアルを提供します。 それでも、この記事で紹介するベスト プラクティスの広範なリストは、WordPress Web サイトを管理しているすべての人にとって読む価値があります。 MySQL サーバーを保護することは、安全な WordPress を維持し、さまざまな種類のブルート フォース攻撃、マルウェア インジェクション、およびその他の種類の攻撃から身を守るための重要なステップです。

目次

  • Database as a Service (DBaaS
  • MySQL を最新の状態に保つ
  • 専用マシンで MySQL を実行する
  • MySQL を IP アドレスにバインドする
  • Web ベースの GUI ツールの使用を制限する
  • 専用ユーザーを使用して MySQL デーモンを実行する
  • mysql_secure_installation スクリプトを使用する
  • 専用の WordPress データベース ユーザーを作成する
  • local_infile が無効になっていることを確認する
  • MySQL コマンド履歴を無効にする
  • –skip-grant-tables 引数を使用して mysqld が開始されていないことを確認します。
  • データベースをバックアップする
    • 頻繁にバックアップを取る
    • バックアップの整合性を頻繁に検証する
    • バックアップを安全に保管する
  • TLS 接続を有効にして適用する
    • テーブルのプレフィックスを変更する
    • 変更の実装方法
    • WordPress を安全に保つ

Database as a Service (DBaaS) の使用を検討する

マネージド プランで WordPress をホストしていない場合は、Database as a Service を検討する価値があります。 MySQL をローカルにインストールする従来のモデルを、接続するサービスに置き換えます。 管理されたデータベース サービスを提供するホスティング プロバイダーで WordPress サイトを実行している場合、これはユース ケースに適している可能性があります。 利用可能なオプションには、通常、Amazon RDS、DigitalOcean マネージド MySQL、および Linode マネージド MySQL が含まれます)。 額面どおり、これらのサービスは MySQL を自分で実行するよりもコストがかかる可能性があります。 ただし、運用グレードのデータベースを実行するという面倒な作業はすべて実行します。 ほとんどのサービスには、セキュリティのベスト プラクティスのプリセット、継続的なセキュリティ パッチとメンテナンス、およびバックアップが含まれています。

Database as a Service (DBaaS) を使用することは、セキュリティと信頼性の点で最良の選択肢の 1 つです。 これは必須ではありませんが、あると便利です。 ただし、MySQL を自分で管理しようとしている場合は、次の強化のヒントを参考にしてください。

MySQL を最新の状態に保つ

WordPress の最新バージョンを実行していることを確認することが重要であるのと同様に、MySQL を最新の状態に保つことが重要です。 他のほとんどのソフトウェアと同様に、MySQL サーバーの更新は定期的にリリースされます。 これらの更新プログラムは、バグに対処し、脆弱性を軽減し、新しい機能を提供します。 既知の脆弱性を持つソフトウェアを実行するリスクを軽減するために、最新のセキュリティ パッチを使用して MySQL を最新の状態に保つ必要があります。 更新したら、「mysql デーモン」を再起動する必要があることに注意してください。 これは、ダウンタイムが発生する可能性があるプロセスです。 いつものように、前もって計画してください。

専用マシンで MySQL を実行する

多くの WordPress インストールでは、MySQL、PHP、および Web サーバー (Nginx や Apache HTTP サーバーなど) が同じマシンで実行されます。 これは、パフォーマンスとセキュリティの両方の点で最適ではありません。 MySQL は、攻撃の爆発範囲を縮小するために、理想的には専用サーバーで実行する必要があります。 攻撃者がWebサーバーの権限を侵害して昇格させた場合、その攻撃者が横方向に移動してMySQLサーバーを侵害することははるかに困難になります.

MySQL を IP アドレスにバインドする

特定の IPv4 または IPv6 インターフェースからの TCP/IP 接続のみを受け入れるように MySQL を構成できます。 bind-address 構成オプションを特定の IP アドレスに設定するだけです。 これにより、クライアント アプリケーション (この場合は WordPress) が MySQL に接続する方法について、追加の制御と制限が提供されます。 デフォルトでは、この設定は * に設定されています。これは、すぐに使用できる MySQL がすべてのインターフェイスでリッスンすることを意味します。

特定の IP をリッスンするように構成されていない場合は、すべての IP を使用して MySQL に接続できます。 この設定は、インターネットに公開している Web サーバーと同じマシンで MySQL を実行している場合に特に重要です (この場合、バインドアドレスを 127.0.0.1 に設定して、MySQL が localhost でのみリッスンするようにする必要があります)。 .

たとえば、MySQL サーバーが特定の IPv4 アドレスでの接続のみを受け入れるようにする場合は、次の例のようなエントリを追加できます。 これは、サーバーの /etc/mysql/mysql.conf.d/mysqld.cnf 構成ファイルの [mysqld] オプション グループの下に入力する必要があります。

bind-address=192.168.0.24

これを設定したら、この IP アドレスを使用してデータベースに接続するように WordPress を再構成する必要があることに注意してください (既にそうしている場合を除く)。これは、他のサーバー ホスト アドレスへの接続が許可されないためです。

Web ベースの GUI ツールの使用を制限する

多くの WordPress インストールには、Web ベースのフロントエンドのグラフィカル管理ツールが含まれています。 一般的な例には、Cpanel、phpMyAdmin、または Adminer が含まれます。 これらのツールにより、MySQL および基盤となるインフラストラクチャのその他の側面の管理が容易になります。 Web ベースのグラフィカル インターフェイスは MySQL データベースの管理に役立ちますが、これらのインターフェイスは別のベクトルを追加することで攻撃対象領域を増やす可能性があります。 さらに、それらが攻撃者によって発見され、悪用されて、データベースに対して破壊的または悪意のある SQL クエリが実行されるリスクがあります。 攻撃により、WordPress Web サイトが完全に乗っ取られることさえあります。

唯一の安全なサーバーは、電源を切ってプラグを抜いたサーバーですが、リスクは管理できます。 重要でないシステムのアンインストールは 1 つのオプションです。 ただし、リスクを最小限に抑えるために、これらをロックダウンおよび制限することもできます。

これらのツールへのアクセスは、さまざまな方法で制限できます。 WordPress 用の phpMyAdmin をリモートでインストールできるため、Web サーバーへのリスクを最小限に抑えることができます。 または、ローカル マシンで MySQL Workbench や Beekeeper Studio などのツールを使用し、SSH トンネル経由でデータベース サーバーに接続することも検討してください。

専用ユーザーを使用して MySQL デーモンを実行する

サーバー上で実行されている他のサービスと同様に、専用ユーザーの下で MySQL デーモンを実行できます。 専用ユーザーを使用して MySQL を実行すると、システム内でそのユーザーに付与される権限を正確に定義できます。 専用ユーザーの下で MySQL を実行することも、最小権限の原則に従います。これは、MySQL の脆弱性の爆発範囲を縮小するためです。 また、制限されたユーザーは MySQL に関係のないリソース (オペレーティング システムの構成やシークレットなど) にアクセスできないため、構成ミスが利用される可能性も減少します。

幸いなことに、パッケージ マネージャー (apt や yum など) を介したインストールでは、MySQL のインストール時にこの手順が自動的に処理されます。 MySQL が専用ユーザーで実行されているかどうかを確認する簡単な方法は、MySQL デーモンを実行しているマシンで次のコマンドを実行することです。

ps -ef | egrep “^mysql.*$”

MySQLが専用ユーザーを使用して実行されている場合、ps の出力から少なくとも 1 行が返されることを期待する必要があります。

mysql_secure_installation スクリプトを使用する

mysql-server パッケージには、mysql_secure_installation というシェル スクリプト ユーティリティが付属しています。 このスクリプトを使用して、MySQL サーバーの安全な開始点を設定できます。 そのため、MySQL の新規インストール後に実行する必要があります。 このユーティリティは次のことに役立ちます。

  • root アカウントのパスワードを設定する
  • localhost の外部からアクセスできる root アカウントを削除する
  • 匿名ユーザー アカウントを削除する
  • テスト データベースを削除します (既定では、匿名ユーザーがアクセスできます)。

mysql_secure_installation を呼び出すには、次のコマンドを実行します。

須藤mysql_secure_installation

セットアップ プロセスが開始されると、MySQL ユーザー用に選択したパスワードの強度をテストするために使用されるValidate Passwordプラグインを有効にするかどうかを尋ねるいくつかのプロンプトが表示されます。 このプラグインを有効にすることをお勧めします。

パスワード検証プラグインを有効にすると、スクリプトはパスワード検証ポリシーを指定するように求めます。 ここでは、強力なパスワード ポリシーを選択する必要があります。 続いて、root ユーザーのパスワードをリセットするよう求められます。

次に、スクリプトは、匿名の MySQL ユーザーを削除するように求めます。 これは、攻撃者が匿名の MySQL ユーザーを利用してデータベース サーバーにアクセスする可能性を減らすために重要です。

次のプロンプトでは、MySQL サーバーへのリモート認証時に root ユーザーを使用したログインを無効にするかどうかを尋ねられます。 root ユーザーを使用したリモート認証は危険であり、ほとんど必要ありません。 代わりに、MySQL に SSH 接続し、サーバー上の MySQL クライアントを使用して root ユーザーとして認証するか、できれば SSH トンネルを使用してリモートの MySQL ポートをローカル マシンに転送し、ローカル クライアントを使用して接続する必要があります。

次に、MySQL に同梱されているデフォルトのデータベース (存在する場合) を削除するよう求められます。 これは、本番 MySQL サーバーで推奨される方法です。

デフォルト データベースの削除

最後に、適用されたすべての変更を有効にするために特権テーブルを再ロードするかどうかを尋ねられます。

専用の WordPress データベース ユーザーを作成する

セキュリティのベスト プラクティスでは、職務または役割によってユーザーと特権を分離する必要があります。 これは、データベースを使用するすべてのアプリケーションが、そのジョブを実行するために必要な最小限の MySQL データベース権限を持つ独自の専用ユーザーを持つ必要があることを意味します。 そのため、ユーザー権限が必要以上にならないようにします。

このプラクティスは、複数の WordPress Web サイトを実行する展開に拡張する必要があります。各 WordPress Web サイトには、専用のデータベースと MySQL ユーザーが必要です。 これにより、一度に 1 人のユーザーのみが 1 つのデータベースにアクセスできるようになり、ユーザーは他のデータベースにアクセスできなくなり、不正アクセスやデータ侵害を回避できます。

次の SQL ステートメント (必要に応じて <host> と <password> と <database> を置き換えます) を使用して、WordPress Web サイトの専用ユーザーを作成し、通常の使用権限を付与できます。 一部の WordPress プラグイン、テーマ、および WordPress の更新では、正しく動作するために追加の権限が必要になる場合があることに注意してください (詳細については、これに関する公式の WordPress ガイダンスを参照してください)。

local_infile が無効になっていることを確認する

LOAD DATA ステートメントを使用すると、データ ファイルをデータベース テーブルにロードできます。 特定の条件下では、これを悪用して MySQL サーバーからファイルを読み取ることができます。 そのため、WordPress サイトでこれに関する特定のユース ケースがない限り、この機能を無効にする必要があります。

MySQL と Web サーバーが同じマシンで実行されている場合、攻撃者が LOAD DATA LOCAL ステートメントを使用して、Web サーバー プロセスが読み取りアクセス権を持つ任意のファイルを読み取ることができる可能性があります。 これは、攻撃者が MySQL に対して任意の SQL ステートメントを実行できることを前提としています。 SQL インジェクションの脆弱性や、悪意のある WordPress プラグインのインストールが原因である可能性があります。 これは、Web サーバーとデータベース サーバーを分離しておくもう 1 つの理由です。

デフォルトでは、local_infile は MySQL 8.0 で無効になっています (以前のバージョンの MySQL ではデフォルトで有効になっていました)。 MySQL サーバーが LOAD DATA LOCAL ステートメントを受け入れないようにするには、mysqld デーモンが local_infile を無効にして開始されていることを確認してください。

MySQL コマンド履歴を無効にする

Linux では、インタラクティブに実行された MySQL クライアント ログ ステートメントは、履歴ファイル (通常は $HOME/.mysql_history にあります) に保存されます。 パスワード、暗号化キー、またはその他の機密情報などの機密情報が公開される可能性が低くなるため、MySQL コマンド履歴は無効にするのが理想的です。

.mysql_history ファイルがシステムに存在しないことを確認するには、次のコマンドを実行します。

find /home -name “.mysql_history”
find /root -name “.mysql_history”

上記のコマンドで出力が返された場合は、.mysql_history ファイルをすべて削除します。 さらに、次のように $HOME/.mysql_history を /dev/null へのシンボリック リンクとして設定できます。

ln -s /dev/null $HOME/.mysql_history

–skip-grant-tables 引数を使用して mysqld が開始されていないことを確認します。

MySQL の root パスワードを紛失した場合、推奨される方法ではありませんが、一部の MySQL 管理者は、MySQL を –skip-grant-tables 引数で開始するように設定することがあります。 このパラメーターを使用して MySQL を起動すると、クライアントが接続またはクエリを実行するときに許可テーブルのチェックが回避され、事実上、誰でも、どこからでも (ネットワーク経由でデータベースにアクセスできる場合)、データベース サーバーで何でも実行できるようになります。

–skip-grant-tables が有効になっていないことを確認するには、サーバーの /etc/mysql/mysql.conf.d/mysqld.cnf 構成ファイルを開き、skip-grant-tables を探します。 値を設定しないか、skip-grant-tables = FALSE に設定する必要があります。

データベースをバックアップする

WordPress データベースのバックアップは、災害や攻撃から迅速に回復できるようにするために絶対に不可欠です。 WordPress データベースをバックアップする方法は無数にあります。WordPress バックアップ プラグインやサービスから、データベース ダンプを定期的に取得する独自のスクリプトまで、以下にいくつかの重要なヒントを示します。

頻繁にバックアップを取る

定期的にバックアップを作成することは非常に明白で自明です。データベースのバックアップを頻繁に作成すればするほど、データ損失インシデントからの復旧が容易になります。 バックアップの頻度は、実行している WordPress サイトのタイプによって異なりますが、経験則として、毎日バックアップを作成することは、ほとんどのユースケースに適しています。

バックアップの整合性を頻繁に検証する

バックアップは、機能する場合にのみ役立ちます。 また、データを回復しようとしているインシデントの最中に発見したくないでしょう。 これに対する簡単な修正方法は、頻繁にテスト リストアを実行して、バックアップが実際に機能することを頻繁に確認することです。 これを行う良い方法は、数か月ごとにカレンダー イベントを設定して復元手順を実行し、バックアップが期待どおりに機能していることを確認することです。 さらに、データベースの復元手順を文書化することも良い考えです。インシデントに対応する際の当て推量が少ないほど良いでしょう。

バックアップを安全に保管する

WordPress サイトのバックアップを Web またはデータベース サーバー (特に Web サーバー) に保存しないでください。 バックアップは、攻撃者がゴミ箱に飛び込む絶好の場所です。 バックアップを安全なオフサイトの場所に保存することを強くお勧めします。 定期的にデータベース ダンプを取得している場合は、データベース ダンプをオブジェクト ストレージ サービスに保存することを検討してください。 これらには、Amazon S3、Cloudflare R2、DigitalOcean Spaces、Linode オブジェクト ストレージなどが含まれます。このルートを使用すると、データベースのバックアップを保存するための優れた費用対効果の高い方法になります。 ただし、使用しているストレージ バケットをパブリックにアクセス可能にしないように特に注意してください。

TLS 接続を有効にして適用する

Web サーバーと同じマシンで MySQL を実行している場合を除き (上記で説明したように、これは理想的なセキュリティ対策ではありません)、Transport Layer Security (TLS 証明書) を使用して WordPress と MySQL の間でデータを暗号化することを強くお勧めします。以前は Secure Socket Layer (SSL 証明書) と呼ばれていました。

デフォルトでは、MySQL をインストールすると、自己署名証明書が自動的に生成されます。 これを確認するには、次を実行します (または、mysql_ssl_rsa_setup スクリプトを使用して新しい証明書を生成することもできます)。

上記のリストから ca.pem を (たとえば SCP 経由で) WordPress Web サイトを実行しているサーバーにコピーする必要があります。 ca.pem ファイルを WordPress サーバーにアップロードしたら、証明書をオペレーティング システムの証明書トラスト ストアに移動し、次のように証明書トラスト ストアを更新する必要があります。

注意、CA 証明書のファイル名は .crt ファイル拡張子で終わる必要があります (たとえば、mysql-ca.crt は有効ですが、mysql-ca.pem.crt または mysql-ca.pem は無効です)。

sudo mv ca.pem /usr/local/share/ca-certificates/mysql-ca.crt
sudo update-ca-証明書

次に、WordPress インストールの wp-config.php ファイルに以下を追加して、MySQL に接続するときに TLS を使用するように WordPress を構成する必要があります。

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

wp-config.php を更新すると、WordPress は TLS を使用して MySQL サーバーへの接続を開始します。

次に、/etc/mysql/mysql.conf.d/mysqld.cnf ファイルに以下を追加して、require_secure_transport システム変数を使用して MySQL サーバーへの TLS 接続を強制することをお勧めします。

require_secure_transport = オン

最後に、MySQL を再起動して変更を有効にします。

systemctl 再起動 mysql

テーブルのプレフィックスを変更する

デフォルトでは、すべての WordPress テーブルは「wp_」プレフィックスで作成されます。 これにより、攻撃者はデータベース テーブルの名前を知っているため、SQL インジェクションなどの特定の攻撃に成功しやすくなります。 これだけではあなたを守ることはできませんが、WordPress の最高のセキュリティ対策として多くの人に推奨されている簡単な方法です。

インストール プロセス中またはその後の任意の時点でデータベース プレフィックスを変更できますが、後者は少し複雑です。 いずれにしても、WordPress データベースのプレフィックスの変更に関するオンライン チュートリアルを見つけることができます。

変更の実装方法

この記事で、WordPress Web サイトを実行するコンテキストにおける MySQL のセキュリティ強化の概要を説明できたことを願っています。 Web サイトのセキュリティに特効薬はありませんが、ある程度の努力をすれば、多層防御のセキュリティ アプローチを採用することで、攻撃者による Web サイトへの攻撃が大幅に困難になります。
このガイドでは、MySQL の強化手法を多数紹介していますが、MySQL は WordPress エコシステムの 1 つのコンポーネントにすぎません。 そのため、WordPress セキュリティ強化ガイドで説明されている WordPress セキュリティの他の側面も考慮する必要があります。 これは、WordPress の 2 要素認証などの実績のあるセキュリティ対策と相まって、可能な限り安全であることを保証するのに役立ちます.

取り入れるのが大変だと感じた場合は、このガイドで説明されているさまざまな強化手法を徐々に適用することができます (おそらく適用する必要があります)。

WordPress を安全に保つ

攻撃者は、安全性の低い Web サイトを悪用するためにそれほど労力を費やす必要がないため、多くの場合、ソフト ターゲットを狙っていることに注意してください。 次の WordPress Web サイトのセキュリティ体制の一歩先を行くことは、あなたを魅力的なターゲットから遠ざけます。