2026年5月20日
2026年5月20日
Sucuri Securityの設定方法|整合性チェック・監査ログ・ハードニング・通知と感染時の対処
Sucuri Securityは、セキュリティ会社のSucuriが配布している無料のWordPressプラグインです(プラグインのスラッグは sucuri-scanner)。WordPress本体のファイルが改ざんされていないかの確認、管理画面での操作の記録、セキュリティ設定の強化(ハードニング)、メールでの通知などを、追加の費用なしで使えます。
この記事は、2026年10月時点の最新版2.8.1の画面とソースコードで確認した内容です。Sucuri Securityの管理画面は、2026年10月時点で日本語への翻訳がほとんど進んでおらず英語で表示されるため、ボタンや項目の名前は英語のまま記載します。
できることと、できないこと
| 機能 | 内容 |
|---|---|
| WordPress Integrity | WordPress本体のファイル(ルート、wp-admin、wp-includes)を、WordPress.orgが配布している同じバージョンのファイルと比べ、変更・追加・削除を一覧にする |
| SiteCheck | Sucuriの外部スキャナー(SiteCheck)がサイトの公開ページを読み込み、マルウェアの兆候やブロックリストへの掲載状況を表示する |
| 監査ログ(Audit Logs) | ログイン、設定の変更、プラグインやテーマの操作などを記録する |
| Last Logins | ログインの成功・失敗、ログイン中のユーザーを一覧にする |
| ハードニング | .htaccess によるPHPの実行禁止、ファイル編集機能の無効化などを、項目ごとに適用・解除する |
| メール通知 | 指定したイベントが起きたときにメールで知らせる |
| 2段階認証 | ユーザーごとに認証アプリによる2段階認証を設定する |
一方で、次のものは無料のプラグインだけでは使えません。
- WAF(Webアプリケーションファイアウォール):Sucuriの有料サービスです。プラグインの「Firewall Management」は、契約したWAFのAPIキーを入れて設定を確認するための画面です
- サーバー内のファイルのマルウェアスキャン:SiteCheckが見るのは、外から見える公開ページだけです。プラグインやテーマ、アップロードされたファイルの中身までは調べません
- プラグインとテーマの整合性チェック:WordPress Integrityの対象はWordPress本体のファイルだけです
手順1:インストールして有効化する
管理画面の「プラグイン」→「プラグインを追加」で「Sucuri Security」を検索してインストールするか、WP-CLIで次を実行します。
wp plugin install sucuri-scanner --activate
有効化すると、管理画面のメニューに「Sucuri Security」が追加されます。主なページは次のとおりです。
| メニュー | 内容 |
|---|---|
| Vulnerability Scanning | ダッシュボード。WordPress Integrity、SiteCheckの結果、推奨設定 |
| Firewall Management | 有料WAFのAPIキーの登録と設定 |
| Two-Factor Authentication | 2段階認証の設定 |
| Events Reporting | 監査ログ(Audit Logs)の表示とCSVのダウンロード |
| Hardening & Prevention | ハードニングの適用・解除 |
| Post-Hack Actions | 感染後の対処(セキュリティキーの更新、パスワードのリセット、プラグインの再インストール) |
| Last Logins | ログインの記録 |
| Settings | 全般設定、スキャン、通知(Alerts)、API通信などの設定 |
プラグインの設定とログは、wp-content/uploads/sucuri/ ディレクトリにファイルとして保存されます。このディレクトリにWebサーバーが書き込めないと、画面の上部に「Storage is not writable」という警告が出ます。その場合は、ディレクトリの所有者と権限を見直してください。
手順2:WordPress本体の整合性を確認する
「Vulnerability Scanning」(ダッシュボード)の「WordPress Integrity」に、WordPress本体のファイルの比較結果が表示されます。問題がなければ、変更されたファイルはありません。
変更・追加・削除されたファイルがあると「Core WordPress Files Were Modified」と表示され、ファイルごとに次の操作を選べます。
- Mark as Fixed:問題がないと判断したファイルを、次回から無視する(意図して変えたファイルなど)
- Restore File:WordPress.orgから元のファイルを取得して上書きする
- Delete File:ファイルを削除する(元に戻せません)
実行には「I understand that this operation cannot be reverted.」へのチェックが必要です。
サーバーにSSHで入れる場合は、WP-CLIでも同じ確認ができます。プラグインについては、WordPress.orgで配布されているものに限り確認できます。
# WordPress本体のファイルを確認(変更されたファイル、本来は無いファイルが Warning として出る)
wp core verify-checksums
# WordPress.org で配布されているプラグインのファイルを確認
wp plugin verify-checksums --all
手順3:SiteCheckでマルウェアとブロックリストを確認する
同じダッシュボードに、SiteCheckの結果が表示されます。マルウェアの兆候がなければ「Site is Clean」、ブロックリストに載っていなければ「Not blocklisted」、載っている場合は「In the blocklist」と表示されます。
SiteCheckは、インターネットから見えるURLを外部から読み込んで調べるサービスです。開発環境や、アクセス制限のあるサイトでは使えません。WordPressをサブディレクトリに置いているなどで、調べるURLを変えたい場合は「Settings」→「API Communication」の「Malware Scan Target」で指定します。
手順4:監査ログを確認し、保存場所を理解する
「Events Reporting」の「Audit Logs」に、ログイン、設定の変更、プラグインやテーマのインストール・有効化などの記録が並びます。2.8では、検索と絞り込み、全件のCSVのダウンロード(「Download CSV」)ができるようになりました。
監査ログは、データベースではなく wp-content/uploads/sucuri/ のファイルに保存されます。保存先をデータベースに切り替える設定はありません。サイトが乗っ取られた場合、攻撃者がこのファイルを書き換えたり消したりできる点に注意してください。
- 記録を別に残したい場合は、「Settings」→「General Settings」の「Log Exporter」を有効にし、ドキュメントルートより上の階層(Webから見えない場所)のファイルを指定します。ログ分析ツールに取り込める形式で書き出されます
- 「Settings」→「API Communication」の「API Service Communication」(ログを外部のAPIに送る機能)は、2.8.1では、送り先のAPIのURLを
wp-config.phpのSUCURISCAN_API_URLに設定した場合だけ有効にできます。設定しなければ、ログはサーバー内だけに保存されます
ログインの記録は「Last Logins」でも確認できます。「Admins」「Logged-in Users」「Failed Logins」などのタブで、管理者のログイン、現在ログイン中のユーザー、失敗したログインを見られます。
手順5:ハードニングを適用する
「Hardening & Prevention」に、強化の項目が並びます。項目ごとに「Apply Hardening」で適用し、「Revert Hardening」で解除します。まとめて適用するボタンはないため、影響を確かめながら1つずつ適用してください。
| 項目 | 内容 |
|---|---|
| Remove WordPress Version | ページのHTMLにWordPressのバージョンを出さない |
| Block PHP Files in Uploads Directory | wp-content/uploads でのPHPの実行を禁止する |
| Block PHP Files in WP-CONTENT Directory | wp-content でのPHPの実行を禁止する |
| Block PHP Files in WP-INCLUDES Directory | wp-includes でのPHPの実行を禁止する |
| Avoid Information Leakage | WordPressの readme.html が残っているかを確認する |
| Verify Default Admin Account | ユーザー名が admin のアカウントがあるかを確認する |
| Disable Plugin and Theme Editor | 管理画面のファイル編集機能を無効にする(DISALLOW_FILE_EDIT) |
| Activate Automatic Secret Keys Updater | セキュリティキーを定期的に自動で変更する |
| Disable XML-RPC | XML-RPC(xmlrpc.php)を無効にする |
PHPの実行を禁止する項目を適用すると、対象のディレクトリの .htaccess に次のルールが追加されます。Apache 2.4の書き方(Require all denied)と、古いApache向けの書き方の両方を含んでいます。
<FilesMatch "\.(?i:php)$">
<IfModule !mod_authz_core.c>
Order allow,deny
Deny from all
</IfModule>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
</FilesMatch>
適用の前に、次の点を確認してください。
- Nginxでは
.htaccessが効きません:Nginxのサーバーでは、ディレクトリごとのPHPの実行禁止をサーバーの設定に書く必要があります。プラグインの画面にも、WordPress公式のNginxの設定例への案内が表示されます wp-contentのPHP禁止は影響が大きい:プラグインやテーマには、wp-content内のPHPファイルを直接呼び出すものがあります。動かなくなったファイルは、同じページの「Allow Blocked PHP Files」で個別に許可できます- セキュリティキーの自動変更:変更のたびに、ログイン中の全員がログアウトされます(WordPressのログインがすぐ切れる原因と対処)
- XML-RPCの無効化:Jetpackなど、XML-RPCを使うプラグインが動かなくなります(WordPressのXML-RPCを無効化する方法)
手順6:メール通知を設定する
「Settings」→「Alerts」で、通知の送り先と内容を設定します。
- Alerts Recipient:通知の送り先のメールアドレス。追加後に「Test Alerts」で届くかを確かめます
- Alert Subject:件名の形式
- Alerts Per Hour:1時間あたりの通知の上限(「Maximum 5 per hour」から「Unlimited alerts per hour」まで)。上限を超えたイベントも、監査ログには記録されます
- Password Guessing Brute Force Attacks:1時間あたり何回のログイン失敗を総当たり攻撃とみなすか
- Security Alerts:通知するイベントの選択。管理者が見ておきたいものとして、次のような項目があります
- Receive email alerts for successful login attempts(ログインの成功)
- Receive email alerts for new user registration(ユーザーの新規登録)
- Receive email alerts when a plugin is installed / activated(プラグインのインストール・有効化)
- Receive email alerts when a file is modified with theme/plugin editor(管理画面のエディターでのファイル変更)
- Receive email alerts for core integrity checks(WordPress本体の整合性チェックの結果)
「Receive email alerts for failed login attempts」は、総当たり攻撃を受けていると大量のメールになります。失敗の把握には「password guessing attacks」の1時間ごとのまとめを使うと、通知の数を抑えられます。
感染が疑われるときの対処
整合性チェックで心当たりのない変更が見つかった、SiteCheckで「Site is not Clean」や「In the blocklist」と表示された場合は、作業の前にファイルとデータベースのバックアップを取り、次の順に進めます。
Post-Hack Actionsを実行する
「Post-Hack Actions」には、感染後に行う操作がまとまっています。
- Update Secret Keys:
wp-config.phpのセキュリティキーを新しくし、盗まれた可能性のあるログインを無効にする(自分も含め全員がログアウトされます) - Reset User Password:選んだユーザーのパスワードを変更し、ログインを終了させ、パスワード再設定のメールを送る
- Reset Installed Plugins:WordPress.orgで配布されているプラグインを再インストールする。有料プラグインなど、WordPress.org以外から入れたものは対象外です
WP-CLIで本体・プラグイン・テーマを入れ直す
よく紹介される wp core download --force は、WordPress本体のファイルを上書きするだけです。プラグインとテーマには手を付けず、攻撃者が追加したファイルも削除されません。次のように、それぞれ確認と入れ直しを行います。
# 1. 本体を同じバージョンで上書き(--skip-content で同梱のテーマ・プラグインは入れない)
wp core download --force --skip-content --version=$(wp core version)
# 2. 本体を再確認。「File should not exist」と出たファイルは、中身を確認して削除する
wp core verify-checksums
# 3. WordPress.org のプラグインを確認し、一致しないものは入れ直す
wp plugin verify-checksums --all
wp plugin install プラグインのスラッグ --force
# 4. アップロード用のディレクトリにPHPファイルが無いかを確認する
find wp-content/uploads -name '*.php'
テーマには、WP-CLIでファイルを照合するコマンドがありません。配布元から入手した元のファイルで入れ直し、子テーマなど自分で変更したファイルは中身を確認してください。
ブロックリストからの解除を依頼する
駆除が終わったら、Googleのブロックリストに載っている場合は、Google Search Consoleの「セキュリティの問題」レポートから審査をリクエストします。原因を取り除かずに依頼しても、解除はされません。
感染の範囲がWordPressの外(サーバーのアカウントやほかのサイト)に及んでいる疑いがある場合は、サーバー全体の対応が必要です(サーバーがハッキングされた時の初動対応手順)。
注意点
- ほかのセキュリティプラグインとの併用:2段階認証や
.htaccessへのルールの追加など、同じ機能を複数のプラグインで重ねて有効にすると、動作が分かりにくくなります。どの機能をどのプラグインで使うかを決めて、重複を避けてください - プラグインを削除するとき:「Settings」→「General Settings」の「Reset Security Logs, Hardening and Settings」を実行すると、サーバー内のログ、ハードニング、設定が削除されます。ログを残したい場合は、先に「Download CSV」で書き出してください
まとめ
- Sucuri Securityの無料プラグインで、本体の整合性チェック、SiteCheckによる外部スキャン、監査ログ、ハードニング、メール通知を使える。WAFは別の有料サービス
- 監査ログは
wp-content/uploads/sucuri/のファイルに保存され、データベースに切り替える設定はない。別に残すならLog Exporterでドキュメントルートの外に書き出す - ハードニングは「Apply Hardening」で1項目ずつ適用し、Nginxでは
.htaccessの項目が効かない点に注意する - 感染時は、Post-Hack Actionsに加え、本体・プラグイン・テーマをそれぞれ入れ直す。
wp core download --forceだけでは本体しか直らない
関連記事: