不正ログインしている人のIPアドレスが変化していると思われます。
sucuriのアラートに記載のIPアドレスをもとに追加してください。
キャッシュがあればすべて削除してください。
ご返信ありがとうございます。
IPアドレスはもちろん、変わるのですがそれだとイタチごっこになります。
不思議なのは、wp-login.php以外でログインアタックする方法があるのでしょうか？
上記設定だと、指定したIPアドレス以外はwp-login.phpもwp-adminにもアクセスできないはずですが。
FilesMatchディレクティブの動作はまず、ファイル名に対して指定したものと合うかどうかを比較し、ヒットした場合には、ディレクティブ内のルールを適用します。よく似たのに、Filesディレクテイブがあり、これもファイル名に対して比較がはたらきます。これはどちらも、ファイル名に対して比較がはたらきます。ですからファイルではないwp-admin（ディレクトリ名）にはマッチしません。つまり、ご指定のディレクティブだと、wp-admin/index.phpなどにはアクセスし放題です。
また、そもそもサーバの設定で.htaccessでFilesMatchディレクトリが許されているのかどうか確認する必要があります。Apacheの場合なら、AllowOverride Allでないと、.htaccessのFilesMatchディレクティブは無視されます。
AllowOverride Allという前提で、wp-admin以下のファイルにアクセスできないようにするには、wp-adminディレクトリ内にディレクティブ指定しないで単純に
Order deny,allow
Deny from all
Allow from 1.1.1.1
Allow from 1.1.1.2
とした上で、フロントエンドで動くプラグインやテーマのJavaScriptがアクセスする可能性の高いadmin-ajax.phpのみ制限を解除するように次の指定を続けます。
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
以上で、指定したIPアドレスのみがアクセスできるようになるでしょう。
なお、これでも改善しない場合、Sucuri がリモートのIPではなくてCDN経由のIPを拾っている可能性があります。Suc uriの動作は詳しくないので、他の人の答えに期待しましょう。
ご回答ありがとうございます。
wp-admin/index.phpもIPアドレスが違うとキッチリと拒否されていますので、
それは違うような気がします。
FilesMatch なので、wp-adminというディレクトリやその文字れるが含まれるファイルへのアクセスを意味するものだと思います。
質問ですが、wp-admin/index.php などもログインしていないとwp-login.phpにリダイレクトがかかりますので、wp-admin/index.phpへのアクセスし放題ということは無いと思うのですが、いかがでしょう？
こんにちは。
wp-login.phpやwp-admin以外のエンドポイント（REST APIやXMLRP）を利用して攻撃を試みているかどうかは、チェック済みでしょうか？
Sucuriは実際のログイン試行だけでなく、REST APIやXMLRPCなどの別のエンドポイントへの攻撃も検出している可能性がありますので、ログを確認してみてください。
XMLRPCは、無効化しておくことをお勧めします。
あと、気になる点としては
allow from 1.1.1.1
allow from 1.1.1.2
は、Cloudflareの公開DNSサービスのIPアドレスですよね？
これを許可IPとして使用するのは、実質的に「全世界からのアクセスを許可」しているのに近い状況で、セキュリティ上のリスクが生じる可能性があると思うのですがどうでしょうか？
Sucuriをりようされているのなら、IP制限だけでなく、二要素認証（2FA）の導入も検討してみてください。
アドバイスありがとうございます。
XMLRPCは無効化を忘れていたので施しました。これで様子みてみます。
IPアドレスはすみません、ここに載せるための適当なアドレスです。
すみません。もしかしてサーバがApacheと違って動作が異なるのであればすみません。
「FilesMatch なので、wp-adminというディレクトリやその文字列が含まれるファイルへのアクセスを意味するものだと思います。」とお書きなので、すみませんが、そのエビデンスを教えていただけませんか？
Apacheのドキュメンテーションでは、FilesMatchについて、「<FilesMatch> ディレクティブは、 <Files> ディレクティブ同様にその中にあるディレクティブの適用範囲をファイル名で制限します。」とあり、Filesディレクティブでは、「このセクション中のディレクティブは、ベース名 (ファイル名の最後の部分) が指定されたファイル名にマッチするすべてのオブジェクトに適用されます。」と、わざわざベース名と指定してパス名は排除しています。
これを素直に読むと、「FilesMatch は ファイル名だけ に適用。ディレクトリにはマッチしない。」となります。ディレクトリを指定したい場合は、<Directory>や<DirectoryMatch>ディレクティブを使用します。ただしこれは.htaccessでは使えないので、そのディレクトリに.htaccessを配置するということになりますが…。
また、逆に説明すると、プラグインやテーマには、「admin-ajax.php」にアクセスするものがあり、アクセスできないと不具合が出ます。これがIPアドレスで制限がかけられていると、allow指定されていないIPアドレスから見ると、サイトに何らかの不具合が出るはずです。それがないということは、現状、wp-adminディレクトリにあるadmin-ajax.phpへは制限がかかっていないということになります。ということは、FilesMatchで指定しているwp-adminは機能していないということではないでしょうか。
FilesMatchの仕様云々の前に、ログインしていない状態でwp-adminのフォルダやファイルにアクセスすると、wp-login.phpにリダイレクトされるものだと認識しております。
なので、wp-admin/index.phpにアクセスし放題というのは少し私の認識とは違いました。
「ログインしていない状態でwp-adminのフォルダやファイルにアクセスすると、wp-login.phpにリダイレクトされるものだと認識しております。」とお書きですが、この認識が間違っています。
Apacheのリダイレクトの場合、例えば、.htaccessなどに
Redirect 301 /a.php /b.php
と書くか、または、
RewriteEngine On
RewriteRule ^a.php$ b.php [R=301,L]
と書くことで実現できます。
この時Apacheは、ブラウザからa.phpが要求されたら、a.phpを開くことなく即座にb.phpを開きます。ですから、b.phpが閲覧制限されていたら、a.phpもまた閲覧制限が適用されます。
ところがwp-admin/index.phpは、そういう正規の意味でのリダイレクトが行われているわけではありません。WordPress の PHP コード（アプリケーションレベル）で実行されている擬似的なリダイレクトです。その動作は次のようになっています。
処理の流れ（ログインしていない場合に wp-admin/index.php にアクセスすると…）
- ブラウザが
https://example.com/wp-admin/index.php にアクセス
- Apache は そのファイルを通常通り処理し、PHP が実行される
wp-admin/index.php → wp-admin/admin.php が読み込まれ、admin.php 内で WordPress コア関数 auth_redirect() が呼ばれる- この関数が「ログインしていない」と判定すると、
wp_redirect( wp_login_url() ); exit; というコードにより、PHP側で wp-login.php へリダイレクト
- ブラウザが
wp-login.php?redirect_to=... に飛ばされる
という流れです。
つまり、一旦index.phpは開かれるわけです。ということは、wp-login.phpにいくらIPアドレス制限をかけても、制限をかけてないindex.phpはアクセスし放題なわけです。もちろん、index.phpで処理された結果転送されたwp-login.phpは開かれないですよ。でも、index.phpは開かれた後なので、ログには制限されているはずのIPアドレスが残るのです。
たしかに、一旦はwp-admin/index.phpにアクセスされますね。
今回、sucuriのアラートメッセージはfailed login ログインユーザー名
なので、ファイルへの不正アクセスというよりは、不正ログイン検知なので、ログインに失敗しているというのは間違い無さそうです。
xmlrpc.php を無効化できていなかったので、無効化し様子を見ております。
今のところ、不正ログインは起きていませんので、また何かありましたら、
ご質問させていただくかもしれません。
大変詳しくありがとうございます。
@ishoji さん
２か月が経過しました。このトピックについて疑問が解消されたのでしたら、ステータスを「解決済」にご変更いただくようお願いいたします。
お世話になります。
皆様のお力添えで何とか問題なく運用できるようになりました。
ありがとうございました。
解決してよかったです。ご連絡ありがとうございます😌
