私がそれを理解したとき、パスワードの検索+ XMLRPCへの多くのリクエストがあることが判明しました。
その結果、すぐにではありませんが、すべてを切断することができました。 これを回避するには、3つの簡単なトリックがあります。
ほとんどの場合、これらの方法は誰もが知っていますが、説明では見つけられなかったいくつかの熊手を踏みました-突然、これは誰かの時間を節約します。
1. Login Login Attemptsプラグインの検索を停止します-他の保護がサーバーを強く中断するため、たとえば、Login Security Solutionプラグインを使用すると、サーバーが30分で停止し、プラグインがデータベースを大量にロードします。
設定では、必ず「プロキシ」のチェックボックスを有効にしてください。そうしないと、全員のサーバーのIPが決定され、全員が自動的にブロックされます。
更新、 DarkByteに感謝、以下のコメントの詳細-直接接続がオンになっているときに定義が機能しない場合にのみ、[プロキシ]ボックスをオンにします
2. XML-RPCを無効にします-XML-RPCプラグインを無効にします（簡単に有効化できます）。
3. wp-login.phpを閉じます-IP経由でサイトにアクセスした場合、プラグインは機能せず、ピッカーは引き続きサイトを攻撃します。 これを回避するには、.htaccessに次を追加します。
<Files wp-login.php> Order Deny,Allow Deny from all </Files>
wp-loginファイルをコピーして、たとえば、poletnormalny.phpなどの奇妙な名前に変更し、自動修正ファイル内で、すべてのwp-login.phpラベルをpoletnormalny.phpに変更します。
これで、ファイルからのみ管理パネルにアクセスできるようになりました。
これらの3つの簡単なステップの後、サイトは再び飛行を開始し、穏やかになりました。
さて、突然面白いです
オプションの1つは、攻撃対象を確認する方法です。 これはnginxログで確認できます（たとえば、Debian / var / log / nginxファイルaccess.logのパスです）。
列挙がある場合、フォームの多くの行が表示されます。
87.230.87.xx--[04 / Aug / 2014：06：35：53 +0400] "POST /wp-login.php HTTP / 1.0" 200 5791 "-" "-"
XMLRPCリクエスト：
95.0.83.xx--[04 / Aug / 2014：06：48：03 +0400] "POST /xmlrpc.php HTTP / 1.0" 499 0 "-" "Mozilla / 4.0（互換性：MSIE 7.0; Windows NT 6.0 ） "