PDF (US Ltr)
- 36.1Mb
PDF (A4)
- 36.2Mb
このページは機械翻訳したものです。
このセクションでは、接続制御プラグイン、CONNECTION_CONTROL および CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS をインストールする方法について説明します。 プラグインのインストールについての一般的な情報は、セクション5.6.1「プラグインのインストールおよびアンインストール」を参照してください。
サーバーで使用できるようにするには、プラグインライブラリファイルを MySQL プラグインディレクトリ (plugin_dir システム変数で指定されたディレクトリ) に配置する必要があります。 必要に応じて、サーバーの起動時に plugin_dir の値を設定してプラグインディレクトリの場所を構成します。
プラグインライブラリファイルのベース名は connection_control です。 ファイル名の接尾辞は、プラットフォームごとに異なります (たとえば、.so for Unix and Unix-like systems, .dll for Windows)。
サーバーの起動時にプラグインをロードするには、--plugin-load-add オプションを使用して、プラグインを含むライブラリファイルに名前を付けます。 このプラグインのロード方式では、サーバーを起動するたびにオプションを指定する必要があります。 たとえば、サーバー my.cnf ファイルに次の行を入力し、必要に応じてプラットフォームの .so 接尾辞を調整します:
[mysqld]
plugin-load-add=connection_control.so
my.cnf を変更したら、新しい設定を有効にするためにサーバーを再起動します。
または、実行時にプラグインをロードするには、次のステートメントを使用して、プラットフォームの .so 接尾辞を必要に応じて調整します:
INSTALL PLUGIN CONNECTION_CONTROL
SONAME 'connection_control.so';
INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS
SONAME 'connection_control.so';
INSTALL PLUGIN はプラグインをただちにロードし、mysql.plugins システムテーブルにも登録して、--plugin-load-add を必要とせずに後続の通常の起動のたびにサーバーがプラグインをロードするようにします。
プラグインのインストールを確認するには、INFORMATION_SCHEMA.PLUGINS テーブルを調べるか、SHOW PLUGINS ステートメントを使用します (セクション5.6.2「サーバープラグイン情報の取得」 を参照)。 例:
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE 'connection%';
+------------------------------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+------------------------------------------+---------------+
| CONNECTION_CONTROL | ACTIVE |
| CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS | ACTIVE |
+------------------------------------------+---------------+プラグインの初期化に失敗した場合は、サーバーエラーログで診断メッセージを確認してください。
プラグインが以前に INSTALL PLUGIN に登録されているか、--plugin-load-add にロードされている場合は、サーバーの起動時に --connection-control および --connection-control-failed-login-attempts オプションを使用してプラグインのアクティブ化を制御できます。 たとえば、起動時にプラグインをロードし、実行時に削除されないようにするには、次のオプションを使用します:
[mysqld]
plugin-load-add=connection_control.so
connection-control=FORCE_PLUS_PERMANENT
connection-control-failed-login-attempts=FORCE_PLUS_PERMANENT
指定された接続制御プラグインなしでサーバーが実行されないようにするには、FORCE または FORCE_PLUS_PERMANENT のオプション値を使用して、プラグインが正常に初期化されない場合にサーバーの起動が強制的に失敗するようにします。
注記
一方のプラグインをもう一方のプラグインなしでインストールすることは可能ですが、完全な接続制御機能を使用するには両方をインストールする必要があります。 特に、CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS プラグインのみのインストールはほとんど使用されません。これは、CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS テーブルに移入するデータを提供する CONNECTION_CONTROL プラグインがない場合、テーブルは常に空になるためです。
操作の構成を有効にするために、CONNECTION_CONTROL プラグインは次のシステム変数を公開します:
connection_control_failed_connections_threshold: サーバーが後続の接続試行の遅延を追加する前に、アカウントに対して許可された連続して失敗した接続試行の数。 失敗した接続カウントを無効にするには、connection_control_failed_connections_thresholdをゼロに設定します。connection_control_min_connection_delay: しきい値を超える接続失敗の最小遅延 (ミリ秒)。connection_control_max_connection_delay: しきい値を超える接続失敗の最大遅延 (ミリ秒)。
connection_control_failed_connections_threshold がゼロ以外の場合、失敗した接続カウントは有効になり、次のプロパティがあります:
connection_control_failed_connections_thresholdによる接続試行の連続失敗により、遅延はゼロになります。その後、サーバーは、接続が成功するまで、後続の連続した試行の遅延を増やします。 未調整の初期遅延は 1000 ミリ秒 (1 秒) から始まり、試行ごとに 1000 ミリ秒増加します。 つまり、アカウントに対して遅延がアクティブ化されると、後続の失敗した試行の未調整の遅延は 1000 ミリ秒、2000 ミリ秒、3000 ミリ秒などになります。
クライアントで発生する実際の遅延は、
connection_control_min_connection_delayおよびconnection_control_max_connection_delayシステム変数の値内に収まるように調整された未調整の遅延です。アカウントの遅延がアクティブ化されると、そのアカウントによって成功した最初の接続でも遅延が発生しますが、後続の接続の失敗カウントはリセットされます。
たとえば、デフォルトの connection_control_failed_connections_threshold 値が 3 の場合、アカウントによる最初の 3 回連続して失敗した接続試行は遅延されません。 4 番目および後続の失敗した接続のために発生する実際の調整済遅延は、connection_control_min_connection_delay および connection_control_max_connection_delay の値によって異なります:
connection_control_min_connection_delayおよびconnection_control_max_connection_delayが 1000 および 20000 の場合、調整された遅延は未調整の遅延と同じで、最大 20000 ミリ秒です。 4 番目以降に失敗した接続は 1000 ミリ秒、2000 ミリ秒、3000 ミリ秒など遅延します。connection_control_min_connection_delayおよびconnection_control_max_connection_delayが 1500 および 20000 の場合、4 番目および後続の失敗した接続の調整済遅延は 1500 ミリ秒、2000 ミリ秒、3000 ミリ秒などで、最大 20000 ミリ秒です。connection_control_min_connection_delayおよびconnection_control_max_connection_delayが 2000 および 3000 の場合、4 番目以降に失敗した接続の調整済遅延は 2000 ミリ秒、2000 ミリ秒および 3000 ミリ秒で、後続のすべての失敗した接続も 3000 ミリ秒遅延します。
CONNECTION_CONTROL システム変数は、サーバーの起動時または実行時に設定できます。 サーバーがレスポンスの遅延を開始する前に、2000 ミリ秒の最小遅延で 4 回連続して失敗した接続試行を許可するとします。 サーバーの起動時に関連する変数を設定するには、サーバーの my.cnf ファイルに次の行を挿入します:
[mysqld]
plugin-load-add=connection_control.so
connection_control_failed_connections_threshold=4
connection_control_min_connection_delay=2000実行時に変数を設定して永続化するには、次のステートメントを使用します:
SET PERSIST connection_control_failed_connections_threshold = 4;
SET PERSIST connection_control_min_connection_delay = 2000;
SET PERSIST は、実行中の MySQL インスタンスの値を設定します。 また、値が保存され、その後のサーバーの再起動に引き継がれます。 後続の再起動に引き継ぐことなく、実行中の MySQL インスタンスの値を変更するには、PERSIST ではなく GLOBAL キーワードを使用します。 セクション13.7.6.1「変数代入の SET 構文」を参照してください。
connection_control_min_connection_delay および connection_control_max_connection_delay システム変数の最小値と最大値はどちらも 1000 および 2147483647 です。 また、各変数に許可される値の範囲は、他の変数の現在の値によっても異なります:
connection_control_min_connection_delayは、connection_control_max_connection_delayの現在の値より大きく設定できません。connection_control_max_connection_delayは、connection_control_min_connection_delayの現在の値より小さく設定できません。
したがって、一部の構成に必要な変更を行うには、特定の順序で変数を設定する必要がある場合があります。 現在の最小遅延および最大遅延が 1000 および 2000 で、3000 および 5000 に設定するとします。 現在の connection_control_max_connection_delay 値 2000 より大きいため、最初に connection_control_min_connection_delay を 3000 に設定することはできません。 かわりに、connection_control_max_connection_delay を 5000 に設定してから、connection_control_min_connection_delay を 3000 に設定します。
CONNECTION_CONTROL プラグインがインストールされると、接続試行がチェックされ、失敗したか成功したかが追跡されます。 このため、失敗した接続試行は、クライアントユーザーとホストが既知の MySQL アカウントと一致するが、指定された資格証明が正しくないか、既知のアカウントと一致しない接続試行です。
失敗した接続数は、各接続試行のユーザー/ホストの組合せに基づきます。 適用可能なユーザー名とホスト名を決定すると、プロキシが考慮され、次のようになります:
クライアントユーザーが別のユーザーをプロキシする場合、失敗した接続カウントのアカウントはプロキシユーザーではなくプロキシユーザーです。 たとえば、
external_user@example.comがproxy_user@example.comをプロキシする場合、接続カウントでは、プロキシユーザーであるproxy_user@example.comではなく、プロキシユーザーであるexternal_user@example.comが使用されます。external_user@example.comとproxy_user@example.comの両方で、mysql.userシステムテーブルに有効なエントリがあり、それらの間のプロキシ関係がmysql.proxies_privシステムテーブルで定義されている必要があります (セクション6.2.18「プロキシユーザー」 を参照)。クライアントユーザーが別のユーザーをプロキシしないが、
mysql.userエントリと一致する場合、カウントではそのエントリに対応するCURRENT_USER()値が使用されます。 たとえば、ホストhost1.example.comから接続しているユーザーuser1がuser1@host1.example.comエントリと一致する場合、カウントにはuser1@host1.example.comが使用されます。 かわりに、ユーザーがuser1@%.example.com、user1@%.comまたはuser1@%エントリと一致する場合、カウントではそれぞれuser1@%.example.com、user1@%.comまたはuser1@%が使用されます。
前述のケースでは、接続試行は mysql.user エントリと一致し、リクエストが成功するか失敗するかは、クライアントが正しい認証資格証明を提供するかどうかによって決まります。 たとえば、クライアントが間違ったパスワードを提示した場合、接続の試行は失敗します。
接続試行が mysql.user エントリと一致しない場合、試行は失敗します。 この場合、使用可能な CURRENT_USER() 値はなく、接続失敗カウントでは、サーバーによって決定されたクライアントおよびクライアントホストによって指定されたユーザー名が使用されます。 たとえば、クライアントがホスト host2.example.com からユーザー user2 として接続しようとすると、クライアントリクエストでユーザー名の部分が使用可能になり、サーバーによってホスト情報が決定されます。 カウントに使用されるユーザー/ホストの組合せは user2@host2.example.com です。
注記
サーバーは、サーバーに接続できるクライアントホストに関する情報を保持します (基本的に、mysql.user エントリのホスト値の和集合)。 クライアントが他のホストから接続しようとすると、サーバーは接続設定の初期段階で試行を拒否します:
ERROR 1130 (HY000): Host 'host_name' is not
allowed to connect to this MySQL server
このタイプの拒否は非常に早く発生するため、CONNECTION_CONTROL ではそれは表示されず、カウントされません。
失敗した接続を監視するには、次の情報ソースを使用します:
Connection_control_delay_generatedステータス変数は、失敗した接続試行に対するレスポンスにサーバーが遅延を追加した回数を示します。 これにより、connection_control_failed_connections_thresholdシステム変数で定義されたしきい値に達するまでに発生する試行はカウントされません。INFORMATION_SCHEMACONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTSテーブルには、アカウント (ユーザー/ホストの組合せ) ごとの接続試行の現在の連続失敗回数に関する情報が表示されます。 これにより、遅延したかどうかに関係なく、失敗したすべての試行がカウントされます。
実行時に connection_control_failed_connections_threshold に値を割り当てると、次の効果があります:
累積されたすべての失敗した接続カウンタがゼロにリセットされます。
Connection_control_delay_generatedステータス変数はゼロにリセットされます。CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTSテーブルが空になります。