攻撃カテゴリ「検知と対応」解説
Attack Categories: Detection and Response

sHub-Log は、WordPress サイトへの脆弱性スキャン、ブルートフォース、情報列挙などの不正アクセス試行をカテゴリ別に検知・記録し、しきい値を超えた IP を一時的に遮断します。以下は検知の仕組みと、各カテゴリの対応内容です（プラグインバージョン 1.3.6 時点）。

sHub-Log detects and logs unauthorized access attempts against WordPress - vulnerability scans, brute-force attacks, information enumeration and more - by category, then temporarily blocks IPs that exceed configured thresholds. The following explains how detection works and how each category is handled (as of plugin version 1.3.6).

仕組みの全体像 / How protection works

保護は次の流れで動作します。

  1. 記録 … 不正アクセスの兆候をカテゴリ別にアタックログ（またはログイン失敗ログ）へ保存します。
  2. しきい値判定 … 同一 IP の記録件数が、時間枠内の制限回数に達したかを判定します。
  3. IP ブロック … 条件を満たすと、その IP からのアクセスを一定時間遮断します。HTTP 403（Forbidden）を返します（バージョン 1.3.0 で、それ以前の 500 から変更）。リダイレクト先 URL を設定している場合は 302 で誘導します。
  4. 自動失効／手動解除 … ブロック時間の経過で自動解除されます。管理画面の「プロテクト IP」から手動解除もできます。

自動ブロックは設定で OFF にでき、その場合は記録のみの運用も可能です（初期値：自動ブロック ON）。

ブロック判定は WordPress の init フック優先度 1 で実行します。テーマの読み込みや本文クエリより前に遮断するため、遮断中の IP からの再アクセスがサーバに与える負荷を抑えられます。

ブロックには 2 つの経路があります。ひとつは上記の「カテゴリ別の検知件数」によるもの、もうひとつがリスクスコアリング（初期 OFF）です。後者は IP ごとにリスク点数を累積し、しきい値到達で遮断します。詳しくは後述の「リスクスコアリングの詳細」をご覧ください。

Protection works in the following sequence:

  1. Log - suspicious signals are saved to the attack log (or the login-failure log) by category.
  2. Threshold check - the plugin checks whether the same IP has reached the allowed count within the time window.
  3. IP block - when the condition is met, access from that IP is blocked for a set period and the site returns HTTP 403 (Forbidden) (changed from 500 in version 1.3.0). If a redirect URL is configured, a 302 redirect is used instead.
  4. Auto-expiry / manual unblock - blocks expire automatically after the duration. You can also unblock from Protected IPs in the admin screen.

Automatic blocking can be turned OFF for a log-only mode (default: automatic blocking ON).

The block check runs on the WordPress init hook at priority 1, before theme loading and the main query, so repeat requests from blocked IPs consume very little server resource.

There are two paths to a block. One is the category-based event count described above; the other is risk scoring (OFF by default), which accumulates a risk score per IP and blocks when a threshold is reached. See "Risk scoring in detail" below.

共通ルール（2系統が独立して動作） / Shared rules (two independent systems)

次の初期値は、ログイン失敗とアタックログの自動ブロックで共有されます。

  • 判定時間枠：5分
  • 制限回数：5回（1.2.12 で 3回から変更）
  • ブロック時間：60分

重要な点として、次の2系統が同じしきい値を使い、それぞれ独立に動きます。

  • ログイン失敗 … パスワード誤りなど、ログイン認証の失敗回数でブロックします（アタックログのカテゴリ一覧・トレンドには出ません）。
  • アタックログ … 各攻撃カテゴリの検知件数でブロックします。ただし「管理画面ハッキング」「ボット偽装」「スコアリング検知」は記録のみ（ソフトカテゴリ）で、この自動ブロック件数には含めません。

1リクエストで複数カテゴリに該当した場合、カテゴリごとに1行記録されるため、その時点でしきい値に達しブロックされることがあります。

ホワイトリストに登録した IP／CIDR、および記憶済みの管理者 IP は、検知・自動ブロックの対象外です。

CDN／リバースプロキシ（Cloudflare 等）をご利用の場合は、実クライアント IP を正しく取得するため、詳細設定の「プライベートプロキシ／Cloudflare の自動信頼」（初期 ON）または「信頼するプロキシ」の設定をご確認ください。未設定のままヘッダだけが付与されている環境では、全訪問者が同一 IP に集約される恐れがあります（管理画面に警告を表示します）。この状態を検知した場合、安全策としてブロック時間を最大5分に自動制限します。

These defaults are shared by login-failure blocking and attack-log auto-blocking:

  • Time window: 5 minutes
  • Limit count: 5 (changed from 3 in 1.2.12)
  • Block duration: 60 minutes

Importantly, the following two systems use the same thresholds but count independently:

  • Login failures - blocks based on failed authentication attempts (does not appear in attack-log category lists or trend charts).
  • Attack log - blocks based on detected attack-category events. However, Admin Area Hacking, Bot Impersonation, and Risk Score Exceeded are log-only (soft categories) and are excluded from this auto-block count.

If one request matches multiple categories, one log row is written per category, so a single request can reach the threshold and trigger a block immediately.

Whitelisted IPs / CIDRs and remembered administrator IPs are excluded from detection and auto-blocking.

If you use a CDN or reverse proxy (e.g. Cloudflare), confirm Advanced Settings > Auto-trust private proxies / Cloudflare (default ON) or Trusted proxies so the real client IP is resolved. If forwarded headers are present but the proxy is not trusted, every visitor may be counted as one IP (an admin warning is shown). When this condition is detected, block duration is automatically capped at 5 minutes as a safety measure.

仕様の前提（読む前に知っておくこと） / Spec premises (read before the category list)

カテゴリ一覧を読むうえで、次の前提を押さえておくと誤解が少なくなります。

  • ログイン失敗は別機能です。「管理画面ハッキング」の説明で触れるブルートフォース本体は、アタックログとは別テーブル・別カウンタで動きます。そのため、パスワード総当たりの記録はカテゴリ一覧や攻撃トレンドには現れません（後述「ログイン失敗」を参照）。
  • 「ログイン試行制限」の名称でも、アタックログ側でも使われます。設定上の時間枠・回数は、ログイン失敗の制限と、アタックログに基づく自動ブロックの両方に流用されます。2系統が同じ数値で、それぞれ独立にカウントします。
  • 1リクエストで複数カテゴリに該当し得ます。該当したカテゴリごとに1行記録されるため、1回のアクセスで共通ルールの回数（初期5回）に達し、その場でブロックされることがあります。
  • 自動ブロックは ON／OFF できます。初期は ON です。OFF にすると検知・記録のみの運用になります（IP は自動では遮断されません）。
  • ソフトカテゴリは「見えるが、自動ブロック件数に入らない」記録です。管理画面ハッキング、ボット偽装、スコアリング検知が該当します。状況把握用のログとして残り、件数によるブロック判定からは除外されます。これらを遮断につなげたい場合は、リスクスコアリングを有効にしてください。
  • スコアリングは初期 OFF です。有効時の初期値は、累積時間枠10分・記録しきい値50・ブロックしきい値100です。配点には各カテゴリに加え、User-Agent が空の信号（ua_empty）も含まれます（全16兆候）。
  • 大量リクエストは固定ウィンドウ方式です。スライディングウィンドウではありません。判定は「以上」（初期では90回目）です。ログイン済みユーザーは初期設定で計測除外、「攻撃特徴を伴うリクエストのみ計測」オプション（初期 OFF）もあります。
  • 404が条件のカテゴリは、WordPress が 404 を返した場合に限ります。プラグイン／テーマ／コア脆弱性スキャンと不審な404多発が該当します。存在しないファイルへの直撃でも、Web サーバや PHP が WordPress を通さず 404 を返す構成では検知できません。
  • REST経路探索は 404 を条件にしません。401 など他の応答でも、同一 IP が短時間に設置場所や REST の入り口を変えながら探索するかを見ます。
  • 検査対象は主に URL のパスとクエリです。POST ボディや Cookie、ヘッダ内容は見ません（詳細は「本プラグインの対象外」）。
  • レート／404／REST経路／スコアの計測カウンタは、専用テーブルに保持されます。オブジェクトキャッシュのフラッシュで計測がリセットされにくい設計です（1.2.12）。
  • 設定に迷った場合は「推奨設定に戻す」ボタンをご利用ください。各設定画面から、動作確認済みの初期値へ一括で戻せます。

Keeping these premises in mind will reduce misunderstandings when reading the category list:

  • Login failures are a separate feature. The brute-force protection mentioned under Admin Area Hacking uses a different table and counter from the attack log. Password-guessing events therefore do not appear in category lists or attack trends (see "Login failures" below).
  • The "login attempt limit" settings are also used for attack-log auto-blocking. The configured window and count apply to both systems; each system counts independently with the same numbers.
  • One request can match multiple categories. Because each match creates one log row, a single access can reach the shared limit (default 5) and be blocked immediately.
  • Automatic blocking can be turned ON/OFF. Default is ON. When OFF, the plugin detects and logs only (IPs are not auto-blocked).
  • Soft categories are "visible but excluded from the auto-block count." Admin Area Hacking, Bot Impersonation, and Risk Score Exceeded remain in the log for visibility but do not increment the shared auto-block counter. To turn these signals into actual blocks, enable risk scoring.
  • Risk scoring is OFF by default. When enabled, defaults are a 10-minute accumulation window, record threshold 50, and block threshold 100. Weights cover every attack category plus an empty User-Agent signal (ua_empty) - 16 signals in total.
  • High-volume requests use a fixed window (not sliding). The check is "greater than or equal" (the 90th request by default). Logged-in users are excluded by default; an optional "count only requests with attack signals" mode is OFF by default.
  • 404-based categories apply only when WordPress returns 404. This covers Plugin / Theme / Core Vulnerability Scan and Suspicious 404 Flood. Probes that never reach WordPress (web server / PHP returns 404 directly) may not be detected.
  • REST Path Probe does not require a 404. Even when the site returns 401 or another status, the plugin looks at whether the same IP varies install locations and REST entry routes in a short time.
  • Inspection mainly covers URL path and query string. POST bodies, cookies, and header contents are not inspected (see "Out of scope").
  • Rate / 404 / REST-path / score counters are stored in a dedicated table so object-cache flushes are less likely to reset measurement (1.2.12).
  • Use the "Restore recommended settings" button if you are unsure. It restores the verified defaults for that settings screen in one click.

カテゴリ別の検知と対応 / Detection and response by category

各カテゴリの記録後、上記の共通ルール（アタックログ系統）により IP ブロックされます。ソフトカテゴリは記録のみです。URL 照合の前には、多重デコード・パス正規化・制御文字除去を行います。

バージョン1.2.12から、検知するカテゴリを11から15としました。（2026年8月8日）バージョン1.3.6から、REST経路探索を追加し、15から16としました。（2026年9月）

After a category is logged, the shared attack-log rules above may block the IP. Soft categories are log-only. Before pattern matching, the plugin normalizes URLs (multi-decode, path normalization, control-character removal).

As of version 1.2.12, the number of detection categories increased from 11 to 15. (August 8, 2026) As of version 1.3.6, REST Path Probe was added, bringing the total from 15 to 16. (September 2026)

１. 大量リクエスト (High Volume Requests)

【検知と対応】同一 IP からのリクエスト数を固定時間枠で数え、しきい値以上で記録します（初期値：1分間に90回／90回目で検知）。HTTP 200 でもカウントします。ログイン済みユーザーは計測から除外（初期 ON）。「攻撃特徴を伴うリクエストのみ計測」オプション（初期 OFF）もあります。正規検索ボット（検証成功時）は計測除外（初期 ON）。AI ボットは初期 OFF（設定で除外可）。

[Detection & response] Counts requests from the same IP in a fixed window and logs when the threshold is reached (default: 90 per minute; triggers on the 90th). HTTP 200 responses are counted. Logged-in users are excluded by default (ON). An optional "count only requests with attack signals" mode is OFF by default. Verified search bots are excluded by default (ON). AI bots are not excluded by default (can be enabled).

２. REST API悪用試行 (REST API Abuse)

【検知と対応】次のパターンへのアクセスを検知します（初期 ON）。

  • /wp-json/wp/v2/users
  • rest_route=/wp/v2/users

投稿編集権限のあるログインユーザーからのアクセスは除外します（ブロックエディタの正規利用を誤検知しないため）。oEmbed（/wp-json/oembed/1.0/embed）は初期 OFF のオプションです。他サイトからの正当な埋め込みを妨げないためです。応答コードは問いません。設置場所や REST の入り口を変えながらの探索は、次項「REST経路探索」で検知します。

[Detection & response] Detects access to these patterns (default ON):

  • /wp-json/wp/v2/users
  • rest_route=/wp/v2/users

Logged-in users who can edit posts are excluded (avoids false positives from the block editor). oEmbed (/wp-json/oembed/1.0/embed) is an optional detector and OFF by default so legitimate embeds from other sites are not blocked. Response status codes do not matter. Scanning that varies install locations and REST entry routes is covered by "REST Path Probe" below.

３. REST経路探索 (REST Path Probe)

【検知と対応】同一 IP が短時間に、WordPress の設置場所や REST API の入り口を変えながら探索するスキャンを検知します（初期 ON。初期値：2分以内に異なる経路が5種類）。/batch/v1 など正規 REST 経路をパス単体で 403 にはしません。実運用のアクセスログで確認された探索パターンを受けて追加した検知です。

次のような「同じ狙いの亜種」を数えます。

  • 設置場所の推測（/wp/ /blog/ /wordpress/ など）
  • /wp-json/ と ?rest_route= と /index.php?rest_route=
  • URLエンコード、大文字・小文字の変更
  • GET と POST の切り替え

応答コードは問いません。サイト側の REST 制限で 401 になっていても、探索のやり方自体を見ます。ログイン済みユーザー、検証済みボット、ホワイトリスト、記憶済み管理者 IP は除外します。ブロックエディタなど、ログイン済みの正規 /batch/v1 利用は対象外です。

本カテゴリはハードカテゴリです。記録後、共通ルール（初期：5分／5回）の自動ブロック件数に算入します。スコアリング有効時は 35 点です。

[Detection & response] Detects scanners that, from the same IP in a short window, vary WordPress install locations and REST API entry routes (default ON; default threshold: 5 distinct variants within 2 minutes). Legitimate REST paths such as /batch/v1 are not blocked by path alone. This detector was added after reconnaissance of this kind was observed in operational access logs.

Distinct variants counted include:

  • Guessed install prefixes (/wp/, /blog/, /wordpress/, etc.)
  • /wp-json/ vs ?rest_route= vs /index.php?rest_route=
  • URL encoding and case changes
  • Switching GET and POST

Response status codes do not matter, so probes that receive 401 from a site-level REST restriction are still counted. Logged-in users, verified bots, whitelisted IPs, and remembered administrator IPs are excluded. Authenticated block-editor use of /batch/v1 is out of scope.

This is a hard category: after it is logged, it counts toward the shared auto-block total (default: 5 events in 5 minutes). When risk scoring is enabled, the weight is 35 points.

４. 管理画面ハッキング (Admin Area Hacking)　※ソフトカテゴリ / soft category

【検知と対応】未ログインで管理系 URL への到達を記録します。対象は主に wp-admin 配下、および wp-login.php への POST です。

  • ログイン画面の GET 表示は対象外です。
  • admin-ajax.php / admin-post.php は対象外です（フロントの正規 AJAX を誤検知しないため）。
  • 記憶済みの管理者 IP は対象外です。

本カテゴリはログに残しますが、共通ルールの自動ブロック件数には含めません。ブルートフォース本体は後述の「ログイン失敗」で対応します。スコアリング有効時は15点の加点対象です。

[Detection & response] Logs unauthenticated access to admin-related URLs - mainly under wp-admin, and POST requests to wp-login.php.

  • GET display of the login form is excluded.
  • admin-ajax.php / admin-post.php are excluded (avoids false positives from front-end AJAX).
  • Remembered administrator IPs are excluded.

This category is logged but excluded from the shared auto-block count. Brute-force password attacks are handled by "Login failures" below. When risk scoring is enabled, this signal is worth 15 points.

５. プラグイン脆弱性スキャン (Plugin Vulnerability Scan)

【検知と対応】パスに /wp-content/plugins/ が含まれ、かつ WordPress が 404 を返したリクエストを記録します。存在しないプラグインファイルへの決め打ちアクセス（脆弱性スキャンの典型）が対象です。実在ファイルへの 200 等は記録しません。

[Detection & response] Logs requests whose path contains /wp-content/plugins/ and for which WordPress returns 404. Typical of probing non-existent plugin files. Successful responses (e.g. 200) to real files are not logged.

６. テーマ脆弱性スキャン (Theme Vulnerability Scan)

【検知と対応】パスに /wp-content/themes/ が含まれ、かつ 404 となったリクエストを記録します。プラグイン脆弱性スキャンと同じ考え方で、テーマ配下への決め打ち探査を検知します。

[Detection & response] Logs requests whose path contains /wp-content/themes/ and that return 404. Same idea as plugin vulnerability scans, for probes under themes.

７. WordPressコア脆弱性スキャン (WordPress Core Vulnerability Scan)

【検知と対応】パスに /wp-includes/ が含まれ、かつ 404 となったリクエストを記録します。コア配下の JS・CSS・PHP 等への決め打ちや、古い脆弱性を狙った探査が対象です。実在コアファイルへの通常アクセスは記録しません。

※プラグイン／テーマ／コアの 404 系カテゴリは、WordPress が 404 を返した場合に限ります。Web サーバが WordPress を通さず直接 404 を返す構成では検知できないことがあります。

[Detection & response] Logs requests whose path contains /wp-includes/ and that return 404. Covers hard-coded probes of core JS/CSS/PHP and scans for old core vulnerabilities. Normal access to real core files is not logged.

* Plugin / theme / core 404 categories apply only when WordPress returns 404. Environments where the web server returns 404 without bootstrapping WordPress may not detect these probes.

８. 設定ファイル探索 (Config File Scan)

【検知と対応】URL パスの末尾要素や、典型的な危険パスへのアクセスを検知します（照合前に URL 正規化・多重デコード）。記事本文に「wp-config」とあるだけの URL は対象にしません。

  • .env、wp-config.php、phpinfo、config.json、database.yml、composer.json など
  • .git / .svn、phpMyAdmin・Adminer、vendor/autoload.php など
  • backup.zip、dump.sql、wordpress.zip など、怪しいバックアップ／ダンプ名（すべての .zip ではありません）

200 でも 404 でも、パターン一致で記録します。

[Detection & response] Detects access to the final path segment or typical sensitive paths (after URL normalization / multi-decode). Article URLs that merely mention "wp-config" in content are not matched.

  • .env, wp-config.php, phpinfo, config.json, database.yml, composer.json, etc.
  • .git / .svn, phpMyAdmin / Adminer, vendor/autoload.php, etc.
  • Suspicious backup/dump names such as backup.zip, dump.sql, wordpress.zip (not every .zip)

Matches are logged regardless of 200 or 404.

９. 裏口探索 (Backdoor Scan)

【検知と対応】shell.php、cmd.php、wso.php、c99.php、r57.php、b374k.php、webshell.php、backdoor.php 等の裏口ファイル名パターンへのアクセスを検知します。加えて、/wp-content/uploads/ 配下の .php / .phtml / .phar 等へのアクセス試行も対象です（アップロード領域での webshell 実行の典型）。存在の有無（200／404）を問わず記録します。スコアリングでは最高配点の50点です。

[Detection & response] Detects access to common backdoor filenames (shell.php, cmd.php, wso.php, c99.php, r57.php, b374k.php, webshell.php, backdoor.php, etc.). Also covers attempts to run .php / .phtml / .phar under /wp-content/uploads/ (typical webshell placement). Logged whether the file exists (200) or not (404). This carries the highest risk-scoring weight: 50 points.

１０. ユーザー列挙 (User Enumeration)

【検知と対応】次を検知します。

  • 数値の ?author=N を、同一 IP が短時間に繰り返す場合（初期：5分以内に5回）
  • /wp-sitemap-users-*.xml へのアクセス（検証済みボットは除外）

きれいなパーマリンクの /author/名前/ への通常閲覧は、この条件には含めません。?author=N の計測では、ログイン済みユーザーと検証済みボットは除外されます。

[Detection & response] Detects:

  • Repeated numeric ?author=N from the same IP in a short window (default: 5 times within 5 minutes)
  • Access to /wp-sitemap-users-*.xml (verified bots excluded)

Normal browsing of pretty permalinks like /author/name/ is not included. Logged-in users and verified bots are excluded from the ?author=N counter.

１１. 不正なクエリパラメータ (Malicious Query)

【検知と対応】URL クエリをパラメータ単位で評価し、SQL インジェクション・XSS・パストラバーサル等の基本攻撃パターンが含まれる場合に記録します（初期 ON）。

サイト内検索（?s=…）のような自然文は、パラメータ単位の判定により誤検知しにくくしています。応答コードは問いません。

[Detection & response] Evaluates the query string parameter by parameter and logs basic SQLi / XSS / path-traversal patterns (default ON).

Natural-language site search (?s=…) is less likely to false-positive because values are checked separately. Response status codes do not matter.

１２. スキャナツール (Scanner Tool)

【検知と対応】User-Agent に、攻撃スキャナとして知られる次のトークンが含まれる場合に記録します（17種）。

sqlmap / nikto / wpscan / masscan / zgrab / zgrab2 / dirbuster / gobuster / ffuf / acunetix / nessus / openvas / havij / nmap / zmeu / morfeus / jorgee

curl、wget、python-requests など、監視・連携で正当に使われる汎用 UA は意図的に対象外としています（誤検知防止のため）。

[Detection & response] Logs User-Agents containing these known attack-scanner tokens (17 patterns):

sqlmap / nikto / wpscan / masscan / zgrab / zgrab2 / dirbuster / gobuster / ffuf / acunetix / nessus / openvas / havij / nmap / zmeu / morfeus / jorgee

Generic clients legitimately used by monitoring and integrations (curl, wget, python-requests, etc.) are deliberately excluded to avoid false positives.

１３. ボット偽装 (Bot Impersonation)　※ソフトカテゴリ / soft category

【検知と対応】Googlebot 等の既知クローラーを名乗る User-Agent でありながら、FCrDNS や公開 IP レンジによる検証に失敗したアクセスを記録します。判定条件は同一 IP から10分以内に5回以上で、単発の検証失敗では記録しません。DNS の一時障害でも検証失敗と同じ見え方になるためです。

本カテゴリは記録のみで、共通ルールの自動ブロック件数には含めません。偽装ボットを実際に遮断したい場合は、リスクスコアリングを有効にしてください（配点40点。初期しきい値では、検知状態のリクエストが3回で100点に達しブロックされます）。

[Detection & response] Logs access that claims a known crawler User-Agent (e.g. Googlebot) but fails FCrDNS or published IP-range verification. The trigger condition is 5 or more occurrences from the same IP within 10 minutes; a single verification failure is not logged, because a temporary DNS outage looks identical.

This category is log-only and excluded from the shared auto-block count. To actually block impersonating bots, enable risk scoring (weight 40 points; with default thresholds, three flagged requests reach 100 points and trigger a block).

１４. スパム・その他 (Spam & Others)

【検知と対応】次を記録します。

  • /xmlrpc.php へのアクセス（コメントスパム・pingback 悪用等を想定。応答コードは問いません）
  • HTTP メソッド P​ROPFIND / T​RACE / T​RACK（W​ebDAV 探査や不正メソッド。O​PTIONS は CORS プリフライトのため対象外）

本カテゴリ名の「スパム」は xmlrpc 経由の悪用を指します。コメントフォーム本体のスパム判定は行いません。

[Detection & response] Logs:

  • Access to /xmlrpc.php (comment spam / pingback abuse; status code ignored)
  • HTTP methods P​ROPFIND / T​RACE / T​RACK (W​ebDAV probing / abusive methods; O​PTIONS is excluded for CORS preflight)

"Spam" in this category name refers to xmlrpc-based abuse. Comment-form body spam is not classified here.

１５. 不審な404多発 (Suspicious 404 Flood)

【検知と対応】存在しない URL への 404 を IP ごとに数え、しきい値超過で記録します（初期値：5分以内に30回）。WordPress が 404 を返した場合が対象です。ログイン済みユーザーと検証済みボットは計測から除外されます。401 と混在する REST 経路の探索は、本カテゴリではなく「REST経路探索」で検知します。

[Detection & response] Counts 404 responses per IP and logs when the threshold is exceeded (default: 30 within 5 minutes). Applies when WordPress returns 404. Logged-in users and verified bots are excluded from the count. REST route discovery mixed with 401 responses is covered by "REST Path Probe", not this category.

１６. スコアリング検知 (Risk Score Exceeded)　※ソフトカテゴリ / soft category

【検知と対応】リスクスコアリングが有効な場合に、IP ごとの累積スコアが記録しきい値（初期50）を超えた時点で記録されるカテゴリです。「この IP は複数の弱い兆候を積み上げている」という警告サインとしてお読みください。

本カテゴリ自体はソフトカテゴリで、件数による自動ブロックには算入しません。実際のブロックはブロックしきい値（初期100）に到達した時点で行われます。仕組みの詳細は次項をご覧ください。

[Detection & response] When risk scoring is enabled, this category is logged the moment an IP's accumulated score exceeds the record threshold (default 50). Read it as a warning sign that the IP is stacking up multiple weak signals.

The category itself is soft and never counts toward the shared auto-block total. The actual block happens when the block threshold (default 100) is reached. See the next section for details.

リスクスコアリングの詳細 / Risk scoring in detail

■ なぜスコアリングが必要か

攻撃の多くは、単体では「クロ」と断定できない小さな兆候の積み重ねとして現れます。User-Agent が空である、Googlebot を名乗るが検証に通らない、404 がやや多い、管理画面 URL に触れている。ひとつずつ見ればグレーでも、同じ IP が10分の間にこれらを次々と踏んでいれば、通常の訪問者ではありません。

カテゴリ別の件数判定は「同じ種類の攻撃を繰り返す相手」に強い一方、種類を変えながら少しずつ探る相手は取りこぼします。リスクスコアリングは、この隙間を埋めるための機能です。

また、ソフトカテゴリ（管理画面ハッキング／ボット偽装）は件数によるブロック対象外のため、これらを遮断につなげる唯一の経路がスコアリングです。偽装ボットを実際に止めたい場合は、必ず有効にしてください。

■ 動作の仕組み

  1. リクエストを検査し、該当した兆候の配点を合計します（同一リクエスト内で同じ兆候を二重加算はしません）。
  2. その点数を、IP ごとのカウンタに加算します。時間枠は固定ウィンドウ方式で初期10分。専用テーブルで管理するため、キャッシュのフラッシュでは消えません。
  3. 累計が記録しきい値（初期50）以上になると、「スコアリング検知」としてアタックログに記録します。
  4. 累計がブロックしきい値（初期100）以上になると、その IP を即座にブロックします（初期60分・HTTP 403）。

■ 配点表（初期値・全16兆候）

  • 50点：裏口探索
  • 45点：スキャナツール
  • 40点：設定ファイル探索／ボット偽装／不正なクエリパラメータ
  • 35点：REST経路探索
  • 30点：ユーザー列挙／不審な404多発／大量リクエスト
  • 25点：プラグイン脆弱性スキャン／テーマ脆弱性スキャン／WordPressコア脆弱性スキャン
  • 20点：REST API悪用試行
  • 15点：管理画面ハッキング／スパム・その他／User-Agentが空（ua_empty）

配点・時間枠・両しきい値は、すべて「リスクスコアリング設定」画面から変更できます。

■ 動作例

  • 例1（偽装ボット）：Googlebot を名乗る未検証アクセスが10分以内に5回到達して「ボット偽装」状態になり、以降のリクエストごとに40点加算。3リクエストで120点に達しブロック。件数判定だけでは止まらない相手を、スコアリングが確実に落とします。
  • 例2（種類を変える探査）：1回目に設定ファイル探索（40点）＋User-Agent が空（15点）で55点となり「スコアリング検知」を記録。続けて裏口探索（50点）で105点となりブロック。合計2リクエストで遮断できます。

■ 誤検知を避けるための除外

次のアクセスは加点対象外です。

  • ホワイトリスト登録済みの IP／CIDR
  • ログイン済みユーザー（初期 ON）
  • 検証済みの正規ボット（検索ボットは初期 ON、AI ボットは初期 OFF で設定変更可）
  • 記憶済みの管理者 IP（そもそも自動ブロックされません）

■ 推奨する導入手順

  1. まずはスコアリング OFF のまま1週間ほど運用し、アタックログで自サイトの実態を把握します。
  2. 次にスコアリングを ON にし、ブロックしきい値を高め（例：200）に設定して「スコアリング検知」の記録だけを観察します。
  3. 誤検知がないことを確認できたら、ブロックしきい値を初期値の100へ戻して本運用に移行します。

攻撃傾向の変化に追随したい場合は、「外部の署名付き配点定義を使用」（初期 OFF）を有効にすると、当社が配布する署名付きの配点定義を利用できます。検証に失敗した場合は管理画面の設定値へ自動的にフォールバックします。

Why scoring matters. Most attacks appear as a series of small signals that are not conclusive on their own: an empty User-Agent, a Googlebot claim that fails verification, slightly elevated 404s, a touch on an admin URL. Individually grey - but when the same IP triggers all of them within ten minutes, it is not an ordinary visitor. Category counting is strong against attackers who repeat one technique, yet it misses those who probe slowly while varying the technique. Risk scoring closes that gap. It is also the only path that turns soft categories (Admin Area Hacking, Bot Impersonation) into real blocks, so enable it if you want impersonating bots stopped rather than merely logged.

How it works.

  1. Each request is inspected and the weights of all matched signals are summed (the same signal is never double-counted within one request).
  2. The points are added to a per-IP counter using a fixed window, 10 minutes by default, stored in a dedicated table so cache flushes do not reset it.
  3. Reaching the record threshold (default 50) writes a "Risk Score Exceeded" entry to the attack log.
  4. Reaching the block threshold (default 100) blocks the IP immediately (60 minutes, HTTP 403, by default).

Default weights (16 signals).

  • 50: Backdoor Scan
  • 45: Scanner Tool
  • 40: Config File Scan / Bot Impersonation / Malicious Query
  • 35: REST Path Probe
  • 30: User Enumeration / Suspicious 404 Flood / High Volume Requests
  • 25: Plugin / Theme / WordPress Core Vulnerability Scan
  • 20: REST API Abuse
  • 15: Admin Area Hacking / Spam & Others / Empty User-Agent (ua_empty)

Weights, the accumulation window, and both thresholds are all editable on the Risk Scoring Settings screen.

Worked examples.

  • Example 1 (impersonating bot): an unverified client claiming Googlebot reaches 5 hits in 10 minutes and enters the Bot Impersonation state; each subsequent request adds 40 points, so three requests reach 120 and trigger a block. Scoring reliably stops what category counting cannot.
  • Example 2 (varied probing): request one matches Config File Scan (40) plus empty User-Agent (15) for 55 points, logging "Risk Score Exceeded"; request two matches Backdoor Scan (50) for 105 points and is blocked. Two requests are enough.

Exclusions that prevent false positives. No points are added for whitelisted IPs/CIDRs, logged-in users (default ON), verified legitimate bots (search bots ON by default, AI bots OFF but configurable), or remembered administrator IPs (which are never auto-blocked).

Recommended rollout. (1) Run with scoring OFF for about a week and study your own attack log. (2) Turn scoring ON with a deliberately high block threshold (e.g. 200) and watch the "Risk Score Exceeded" entries only. (3) Once you confirm there are no false positives, return the block threshold to the default 100 for live protection. If you would rather track evolving attack trends automatically, enable "Use remote scoring definition" (OFF by default) to consume our signed weight definitions; the plugin falls back to your admin settings whenever retrieval or signature validation fails.

ログイン失敗（ブルートフォース対策） / Login failures (brute-force protection)

【検知と対応】WordPress のログイン失敗（wp_login_failed）を専用テーブルに記録し、共通ルールと同じ時間枠・回数（初期：5分／5回）で IP をブロックします。

  • アタックログのカテゴリ一覧やトレンドグラフには表示されません（別系統のログです）。
  • 管理者（manage_options）がログイン成功した IP は、最大20件・30日間記憶されます（初期 ON）。記憶中の IP は自動ブロックされず、ログイン失敗の許容回数も10回に緩和されます。
  • 導入直後は、ご自身の IP をホワイトリストへ登録することを推奨します。

[Detection & response] Failed WordPress logins (wp_login_failed) are stored in a dedicated table and blocked using the same shared window/count (default: 5 minutes / 5 attempts).

  • These events do not appear in attack-log category lists or trend charts (separate logging path).
  • IPs of users with manage_options who log in successfully are remembered for up to 20 addresses and 30 days (default ON). Remembered IPs are never auto-blocked and their login-failure allowance is relaxed to 10 attempts.
  • Right after install, whitelist your own IP.

ボット除外の仕組み / Bot exclusion

User-Agent 文字列だけでは信用しません。既知クローラーを名乗るアクセスに限り素性を検証し、検証に成功したボットだけを、大量リクエスト・404多発・REST経路探索・スコアリング・ユーザー列挙などの計測から除外できます。

検証対象は20のボット定義（検索系10種・AI系10種）です。

  • 検索系ボット（10種） … Googlebot / Bingbot / MSNBot / Yahoo! Slurp / DuckDuckBot / YandexBot / Baiduspider / Mediapartners-Google / AdsBot-Google / APIs-Google。逆引き＋正引き（FCrDNS）で検証し、IPv6 は AAAA レコードで正引き確認します。除外は初期 ON。
  • AI 系ボット（10種） … GPTBot / ChatGPT-User / OAI-SearchBot / ClaudeBot / Claude-Web / PerplexityBot / Perplexity-User / CCBot / Bytespider / Applebot。各社が公開する IP レンジ（OpenAI・Anthropic・Perplexity・Common Crawl・Apple）と照合し、一部は FCrDNS も併用します。除外は初期 OFF（設定で ON 可）。

公開 IP レンジは自動取得して24時間キャッシュし、取得に失敗した場合は同梱のバックアップへフォールバックします。検証結果は12時間キャッシュするため、リクエストごとに DNS を引くことはありません。ボットの選別処理自体がサーバ負荷になりにくい設計です。

検証に失敗した「ボットを名乗るアクセス」は、上記「ボット偽装」として記録対象になります。なお、ボット定義はフィルターフック（syntaxhub_securelog_known_bot_definitions）で追加・変更できます。

User-Agent strings alone are never trusted. Only clients that claim a known crawler are verified, and only those that pass verification can be excluded from high-volume, 404-flood, REST path probe, scoring, and user-enumeration measurement.

Verification covers 20 bot definitions (10 search, 10 AI):

  • Search bots (10) - Googlebot / Bingbot / MSNBot / Yahoo! Slurp / DuckDuckBot / YandexBot / Baiduspider / Mediapartners-Google / AdsBot-Google / APIs-Google. Verified with reverse + forward DNS (FCrDNS); IPv6 uses AAAA for the forward check. Exclusion default: ON.
  • AI bots (10) - GPTBot / ChatGPT-User / OAI-SearchBot / ClaudeBot / Claude-Web / PerplexityBot / Perplexity-User / CCBot / Bytespider / Applebot. Matched against vendor-published IP ranges (OpenAI, Anthropic, Perplexity, Common Crawl, Apple), with FCrDNS as an additional method for some. Exclusion default: OFF (can be enabled).

Published IP ranges are fetched automatically and cached for 24 hours, falling back to bundled copies if retrieval fails. Verification results are cached for 12 hours, so DNS is not queried on every request - bot classification itself adds negligible server load.

Access that claims to be a bot but fails verification may be logged as Bot Impersonation above. Bot definitions can be extended or overridden through the syntaxhub_securelog_known_bot_definitions filter.

メール通知（任意） / Email alerts (optional)

詳細設定から有効化できます（いずれも初期 OFF）。

  • アタック急上昇アラート … カテゴリ別の急増を検知してメール通知（クールダウンあり）。
  • 高止まりアタック量アラート … 時間枠内の合計検知件数がしきい値を超えた場合に通知（初期：6時間で500件、最大1日1通）。

通知先メールアドレスは設定画面で指定できます。外部の署名付き定義を使うオプションもあります。

Enable from Advanced Settings (both OFF by default):

  • Attack spike alerts - email when a category surges (with cooldown).
  • Sustained volume alerts - email when total detections in a window exceed a threshold (default: 500 in 6 hours; at most one email per day).

Recipients are configurable. An option to use signed remote definitions is also available.

記録される情報 / Data recorded

アタックログ等には、主に次が保存されます。

  • IP アドレス
  • リクエスト URL
  • カテゴリ
  • User-Agent
  • 日時

保存期間は無料版14日／有料版90日で固定です（管理画面では確認のみで、任意の日数は指定できません）。古いログは WP-Cron で日次削除されます。アタックログの一覧は100件ずつ表示され、カテゴリでの絞り込みと CSV エクスポートに対応しています。

ボットアクセスログ（検証済みボットの記録）は初期 OFF です。有効化すると検索ボットは記録 ON、AI ボットは記録 OFF が初期値となります。保存期間はアタックログと同じ扱いです。

これらのログはすべてお客様のサイトのデータベース内に保存されます。攻撃ログや IP アドレスが当社サーバへ送信されることはありません。ただし IP アドレスは個人データに該当し得るため、サイトのプライバシーポリシーへの記載をご検討ください。

Attack logs mainly store:

  • IP address
  • Request URL
  • Category
  • User-Agent
  • Timestamp

Retention is fixed at 14 days (free) / 90 days (paid); the admin screen displays the current value but arbitrary periods cannot be set. Older rows are purged daily by WP-Cron. The attack log lists 100 rows per page and supports category filtering and CSV export.

Bot access logging (records of verified bots) is OFF by default. When enabled, search-bot logging defaults to ON and AI-bot logging to OFF. Retention follows the same policy as attack logs.

All of these logs stay inside your own site database. Attack logs and IP addresses are never transmitted to our servers. Note that IP addresses may still constitute personal data, so consider stating this in your site privacy policy.

本プラグインの対象外 / Out of scope

sHub-Log は「アクセス試行の検知と IP 単位の一時遮断」に特化しています。次は対象外、または別レイヤでの対策が必要です。

  • POST ボディ・Cookie・HTTP ヘッダの中身は検査しません（検査対象は主に URL のパスとクエリ）。WAF の代替にはなりません。
  • 遮断はアプリケーション層（PHP）です。.htaccess や CDN／ファイアウォールでの遮断ではないため、ブロック済み IP からのリクエストでも WordPress と DB は起動します（init 優先度1で早期に遮断し、負荷は最小化しています）。大規模な DoS／DDoS の負荷軽減には向きません。
  • ブロック中のアクセスはアタックログに残りません（遮断が先に行われるため）。そのため統計上の件数は実際の試行より少なく見えます。ただしバージョン1.3.0 以降、遮断後の再アクセスは「プロテクト IP」画面で拒否回数・最終拒否日時・最終リクエスト URLとして集計されます。「攻撃が止まったのか、遮断が効いているのか」をここで確認できます。
  • 分散型・短時間ローテーション（多数 IP がそれぞれ数回だけ叩く）には効きにくい場合があります。
  • ファイル改ざん検知、マルウェアスキャン、既に設置された裏口の発見は行いません。
  • コメントフォームのスパム本文判定は行いません（xmlrpc へのアクセス試行は検知します）。
  • Web サーバが WordPress を通さず返す 404 は、プラグイン／テーマ／コアの 404 系カテゴリでは検知できません。
  • robots.txt の制御や国別ブロックは行いません。ボットは「遮断」ではなく「検証と選別」で扱う設計です。

sHub-Log focuses on detecting access attempts and temporarily blocking IPs. The following are out of scope or need other layers:

  • POST bodies, cookies, and HTTP header contents are not inspected (mainly URL path and query). This is not a WAF replacement.
  • Blocking is at the application layer (PHP). It is not .htaccess / CDN / firewall blocking, so blocked IPs still bootstrap WordPress and the database (the check runs early, at init priority 1, to keep this cost minimal). It is not suited to absorbing large DoS/DDoS load.
  • Requests from already-blocked IPs are not added to the attack log (blocking runs first), so statistics under-count real attempts. Since version 1.3.0, however, post-block traffic is aggregated on the Protected IPs screen as denial count, last blocked time, and last request URL - useful for telling whether an attack stopped or is still being absorbed.
  • Distributed / short IP rotation (many IPs each making only a few requests) may be less effective.
  • File integrity monitoring, malware scanning, and discovery of already-planted backdoors are not performed.
  • Comment-form spam body classification is not performed (xmlrpc access attempts are detected).
  • 404s returned by the web server without WordPress are not covered by plugin/theme/core 404 categories.
  • robots.txt management and country-level blocking are not provided. Bots are handled by verification and classification rather than blanket blocking.

誤検知が出たときの対処 / If you see false positives

  1. ご自身・事務所の IP をホワイトリストに登録する（最優先）。
  2. 管理者アカウントで一度ログインし、管理者 IP の記憶を効かせる（初期 ON）。
  3. CDN／LB 利用時は信頼プロキシ／自動信頼が有効か確認する。
  4. しきい値（回数・時間枠・大量リクエスト・404多発）を緩和する。
  5. スコアリング利用中は、ブロックしきい値を引き上げるか、該当兆候の配点を下げる。
  6. 該当カテゴリの検知を OFF にする、または自動ブロックを OFF にして記録のみ運用する。
  7. 誤ってブロックされた IP は、管理画面のプロテクト IP 一覧から解除する。
  8. 設定を戻したい場合は、各設定画面の「推奨設定に戻す」で初期値に一括復元する。
  1. Whitelist your own / office IP first.
  2. Log in once as an administrator so remembered admin IPs take effect (default ON).
  3. If you use a CDN/LB, confirm trusted proxies / auto-trust are configured.
  4. Relax thresholds (count, window, high-volume, 404 flood).
  5. If risk scoring is enabled, raise the block threshold or lower the weight of the signal involved.
  6. Turn off the relevant detector, or turn off auto-blocking for log-only mode.
  7. Unblock mistaken IPs from the Protected IP list in the admin screen.
  8. Use "Restore recommended settings" on any settings screen to return to verified defaults.