diff --git a/docs/.vuepress/config-client/documents.ts b/docs/.vuepress/config-client/documents.ts index 4cbb3c7e..de4400fe 100644 --- a/docs/.vuepress/config-client/documents.ts +++ b/docs/.vuepress/config-client/documents.ts @@ -111,7 +111,7 @@ export default [ }, { title: "WordPress Plugin", - description: "Documentation for Imunify Security plugin for WordPress available in Imunify360.", + description: "Imunify Security plugin for WordPress: a guide for WordPress site owners, and a guide for hosting providers.", link: "/wordpress_plugin/", } ] diff --git a/docs/.vuepress/config-client/sidebar.ts b/docs/.vuepress/config-client/sidebar.ts index d2c83e43..42e9fa8a 100644 --- a/docs/.vuepress/config-client/sidebar.ts +++ b/docs/.vuepress/config-client/sidebar.ts @@ -190,7 +190,8 @@ export default { { collapsable: false, children: [ - "/wordpress_plugin/" + ["/wordpress_plugin/", "Site Owner Guide"], + ["/wordpress_plugin/hosting_providers/", "Hosting Provider Guide"] ] } ], diff --git a/docs/.vuepress/theme/util.js b/docs/.vuepress/theme/util.js index 78efcad3..834c6d43 100644 --- a/docs/.vuepress/theme/util.js +++ b/docs/.vuepress/theme/util.js @@ -259,9 +259,12 @@ function ensureEndingSlash(path) { function resolveItem(item, pages, base, isNested) { if (typeof item === 'string') return resolvePage(pages, item, base) - else if (Array.isArray(item)) return Object.assign(resolvePage(pages, item[0], base), { - title: item[1] - }) + else if (Array.isArray(item)) { + // Pages are loaded asynchronously, so a page may not be resolvable yet. + // Return null in that case, like the string branch above does. + const page = resolvePage(pages, item[0], base) + return page ? Object.assign(page, {title: item[1]}) : null + } else { if (isNested) console.error( '[vuepress] Nested sidebar groups are not supported. ' + diff --git a/docs/command_line_interface/README.md b/docs/command_line_interface/README.md index a677f46b..7fdaa38a 100644 --- a/docs/command_line_interface/README.md +++ b/docs/command_line_interface/README.md @@ -2780,6 +2780,8 @@ imunify360-agent whitelisted-crawlers [command] This command manages the Imunify Security WordPress plugin and its Web Application Firewall (WAF). It is available in both Imunify360 (using `imunify360-agent`) and ImunifyAV/AV+ (using `imunify-antivirus`). +For requirements, installation, and what site owners can change, see the [Hosting Provider Guide](/wordpress_plugin/hosting_providers/). + **Usage:**
@@ -2846,6 +2848,50 @@ imunify360-agent config update '{"WORDPRESS":{"waf_default": true}}'
+### Check the WAF status of accounts + +Use `waf status` to report the effective WAF status of every hosting account, and where that status comes from — the server-wide default, or a per-account override. + +| | | +|-|-| +|`--user`|show only this hosting account.| +|`--status`|show only accounts whose effective status is `enabled` or `disabled`.| +|`--source`|show only accounts whose status comes from the `default` or from a per-account `override`.| +|`--limit`|maximum number of accounts to return. The server caps this at 500.| +|`--offset`|number of accounts to skip. Default is `0`.| + +**Examples** + +1. Report the status of all accounts: + +
+ +``` +imunify360-agent wordpress-plugin waf status +``` + +
+ +2. List the accounts where the WAF is currently off, as JSON: + +
+ +``` +imunify360-agent wordpress-plugin waf status --status disabled --json +``` + +
+ +3. Report the status of one account: + +
+ +``` +imunify360-agent wordpress-plugin waf status --user alice +``` + +
+ ### Manage individual WAF rules Use the `rules` subcommand to disable or re-enable a specific WAF rule — for example, one that interferes with legitimate traffic. The rule identifier is the one shown for the incident (typically a CVE ID). @@ -2903,31 +2949,115 @@ imunify360-agent wordpress-plugin rules list-disabled -### AI Bot Management +### List WordPress sites -AI Bot Management (bot classification and per-category rate limiting) is controlled through configuration keys rather than a dedicated subcommand. The plugin must be installed first (see `security_plugin_enabled`). Site owners can also manage it from the WordPress dashboard — see [AI Bot Management](/wordpress_plugin/#ai-bot-management). +Use `list-sites` to list the WordPress sites where the Imunify Security plugin is installed. This is the quickest way to check the result of a rollout across a server. -Enable or disable it server-wide: +| | | +|-|-| +|`--user`|show only the sites of this hosting account.| +|`--limit`|maximum number of sites to return. Default is `50`.| +|`--offset`|number of sites to skip. Default is `0`.| + +**Examples** + +1. List the first 50 sites with the plugin installed:
``` -imunify360-agent config update '{"WORDPRESS":{"ai_bot_protection": true}}' -imunify360-agent config update '{"WORDPRESS":{"ai_bot_protection": false}}' +imunify360-agent wordpress-plugin list-sites ```
-Enable it for a single hosting account: +2. List the sites of one hosting account:
``` -imunify360-agent config update --user user1 '{"WORDPRESS":{"ai_bot_protection": true}}' +imunify360-agent wordpress-plugin list-sites --user alice ```
+3. Page through a longer list: + +
+ +``` +imunify360-agent wordpress-plugin list-sites --limit 100 --offset 100 +``` + +
+ +### List WAF incidents + +Use `list-incidents` to list the requests the WordPress WAF acted on. The same incidents are shown to site owners in the WordPress admin area — see [Managing WAF incidents](/wordpress_plugin/#managing-waf-incidents). + +| | | +|-|-| +|`--user`|show only incidents of this hosting account.| +|`--by-domain`|show only incidents for this domain.| +|`--site-search`|show only incidents for sites whose path matches this value.| +|`--by-abuser-ip`|show only incidents from this source IP address.| +|`--by-country-code`|show only incidents from this country.| +|`--search`|search by IP address, name, or description.| +|`--since`|show incidents at or after this Unix timestamp.| +|`--to`|show incidents at or before this Unix timestamp.| +|`--order-by`|fields to sort by, each followed by `+` (ascending) or `-` (descending). Supported fields: `timestamp`, `severity`, `domain`, `abuser`.| +|`--limit`|maximum number of incidents to return. Default is `50`.| +|`--offset`|number of incidents to skip. Default is `0`.| + +**Examples** + +1. List the most recent incidents: + +
+ +``` +imunify360-agent wordpress-plugin list-incidents +``` + +
+ +2. List the incidents of one domain, most severe first: + +
+ +``` +imunify360-agent wordpress-plugin list-incidents --by-domain example.com --order-by severity- +``` + +
+ +3. List the incidents caused by one IP address: + +
+ +``` +imunify360-agent wordpress-plugin list-incidents --by-abuser-ip 203.0.113.10 +``` + +
+ +### AI Bot Management + +AI Bot Management (bot classification and per-category rate limiting) is controlled through configuration keys rather than a dedicated subcommand. The plugin must be installed first (see `security_plugin_enabled`). Site owners can also manage it from the WordPress dashboard — see [AI Bot Management](/wordpress_plugin/#ai-bot-management). + +Enable or disable it server-wide: + +
+ +``` +imunify360-agent config update '{"WORDPRESS":{"ai_bot_protection": true}}' +imunify360-agent config update '{"WORDPRESS":{"ai_bot_protection": false}}' +``` + +
+ +This is a server-wide setting. Unlike `waf_enabled`, it cannot be set for a single hosting account — once it is on for the server, a site owner controls it for their own site from the WordPress dashboard. + Set the default preset applied to sites that have not chosen their own — one of `balanced`, `strict`, or `monitor`:
diff --git a/docs/config_file_description/README.md b/docs/config_file_description/README.md index d2abbde9..ac3045e4 100644 --- a/docs/config_file_description/README.md +++ b/docs/config_file_description/README.md @@ -449,13 +449,13 @@ systemctl restart imunify360 # enable (True) the Malware Database Scanner - a database antivirus with automated malware detection and clean-up of web applications. Requires MariaDB/MySQL DB management system version 5.5. Recommended version is 5.6+. Note, that only WordPress, Joomla, and Magento databases are supported now. WORDPRESS: security_plugin_enabled: False -# installs the Imunify Security WordPress plugin on all WordPress sites. This is the master switch for the WordPress plugin, its WordPress WAF, and AI Bot Management. Default is False. +# installs the Imunify Security WordPress plugin on all WordPress sites. This is the master switch for the WordPress plugin, its WordPress WAF, and AI Bot Management. Default is False. See the Hosting Provider Guide. waf_enabled: True # enables the WordPress WAF (virtual patching) for WordPress sites on the server. When set to False, WAF rules are removed from all sites. Can also be set per hosting account. Default is True. waf_default: False # whether the WordPress WAF is enabled automatically for newly created hosting accounts. Default is False. ai_bot_protection: False -# enables AI Bot Management (bot classification and per-category rate limiting) for WordPress sites on the server. Can also be set per hosting account; a site owner may override it from the WordPress dashboard. Default is False. +# enables AI Bot Management (bot classification and per-category rate limiting) for WordPress sites on the server. This is a server-wide setting only; a site owner may override it for their own site from the WordPress dashboard. Default is False. ai_bot_protection_preset: balanced # the default AI Bot Management preset applied to sites that have not chosen their own. One of balanced, strict, or monitor. Default is balanced. diff --git a/docs/dashboard/README.md b/docs/dashboard/README.md index 76302a15..9ee52165 100644 --- a/docs/dashboard/README.md +++ b/docs/dashboard/README.md @@ -1574,11 +1574,7 @@ Click _Save changes_ button on the bottom of th #### WordPress plugin -:::warning -The WordPress plugin installation is currently allowed only if _Settings > Malware > General > Default action on detect_ is set to _Cleanup_. Other installation options will be introduced in the future release. -::: - -Tick the _Install WordPress plugin_ checkbox to install the Imunify Security WP plugin on all WordPress sites. +Tick the _Install WordPress plugin_ checkbox to install the Imunify Security WP plugin on all WordPress sites. For requirements, rollout, and these settings in one place, see the [Hosting Provider Guide](/wordpress_plugin/hosting_providers/). You can also enable it via CLI with the following command: diff --git a/docs/wordpress_plugin/README.md b/docs/wordpress_plugin/README.md index e865621f..34f9930a 100644 --- a/docs/wordpress_plugin/README.md +++ b/docs/wordpress_plugin/README.md @@ -1,31 +1,36 @@ -# Imunify Security Plugin for WordPress +--- +title: 'Imunify Security Plugin for WordPress: Site Owner Guide' +description: What the Imunify Security plugin for WordPress does, why your hosting provider installed it, how to use its malware, firewall, and bot protection features, and answers to common questions from WordPress administrators. +--- + +# Site Owner Guide [[toc]] -## Overview +::: tip Are you a hosting provider or server administrator? +This page is written for **WordPress site owners**. It explains what the plugin does, what you see in your WordPress dashboard, and what you can change yourself. + +If you run the server, see the [Hosting Provider Guide](/wordpress_plugin/hosting_providers/) for requirements, installation, and server-wide settings. +::: -The **Imunify Security plugin for WordPress** is available to all Imunify customers (ImunifyAV, ImunifyAV+, and Imunify360). It provides WordPress administrators with a modern interface, real-time malware and security status, and a seamless upgrade path from AV to 360. The plugin is designed to enhance your website's security and user experience directly from the WordPress dashboard. +## What the plugin does -## Prerequisites +The **Imunify Security plugin for WordPress** shows the security status of your website directly in the WordPress dashboard. It reports what the Imunify security software on your hosting server found and cleaned, and it adds two protection layers that run inside WordPress itself. -* **WordPress Version**: 5.0.0 or higher -* **PHP Version**: 5.6 or higher -* **Imunify360**: 8.4.1 or higher -* **ImunifyAV/AV+**: 8.6.0 or higher +You do not need to buy, download, or configure anything. The plugin works together with the Imunify product your hosting provider already runs on the server (ImunifyAV, ImunifyAV+, or Imunify360). -## Installation +### Why the plugin is on your site -The plugin is not available in the WordPress plugin repository. To install: +Your hosting provider installed the plugin for you, as part of the security service included with your hosting plan. This is why it appears in your plugin list without you installing it, and why you cannot find it in the WordPress.org plugin directory — it is delivered by the hosting server, not from the public repository. -1. Navigate to Imunify settings in your hosting control panel (e.g., cPanel). -2. Open the `General` tab. -3. Scroll to the `WordPress Plugin` section. -4. Tick the `Install WordPress plugin` checkbox and click `Save changes`. -5. The plugin will be installed in the background to all active WordPress installations on the server. +### What it protects you from -![](/images/wordpress-plugin/panel-settings.png) +* **Malware.** Infected files, injected code, and backdoors. The Imunify scanner on the server checks your files, and the plugin shows you what was detected and cleaned. +* **Zero-day attacks and dangerous code execution.** Attacks that use undisclosed vulnerabilities, and backdoors that are already on the site, run PHP code that no scanner has a signature for yet. Proactive Defense stops that code at the moment it tries to run. +* **Exploits of known vulnerabilities** in the plugins, themes, and WordPress core you use — including the time between a vulnerability becoming public and you installing the update. The Web Application Firewall (virtual patching) blocks the attempt without changing any of your files. See [Web Application Firewall](#web-application-firewall-virtual-patching). +* **Aggressive crawlers, scrapers, and AI bots** that slow your site down, use up its resources, and copy its content. AI Bot Management limits them while leaving real visitors untouched. See [AI Bot Management](#ai-bot-management). -*Plugin installation settings in the control panel* +Which of these are available depends on the Imunify product your hosting provider runs. ImunifyAV and ImunifyAV+ users see a smaller set of features than Imunify360 users. ## Features @@ -35,8 +40,8 @@ The plugin adds a dashboard widget that helps administrators keep track of their - Real-time security status - Proactive Defense status -- Web Application Firewall status and recent WAF incidents (see [Web Application Firewall](/wordpress_plugin/#web-application-firewall-virtual-patching)) -- Bot Protection status and recent bot activity (see [AI Bot Management](/wordpress_plugin/#ai-bot-management)) +- Web Application Firewall status and recent WAF incidents (see [Web Application Firewall](#web-application-firewall-virtual-patching)) +- Bot Protection status and recent bot activity (see [AI Bot Management](#ai-bot-management)) - Timestamps for last and next scheduled scans - Detailed list of detected and cleaned malware (file path, signature, detection or clean-up time) @@ -85,9 +90,9 @@ ImunifyAV users are shown a limited interface and prompted to upgrade to Imunify The Imunify Security plugin includes a **Web Application Firewall (WAF)** that provides *virtual patching* for WordPress. It protects your sites against known vulnerabilities (CVEs) in WordPress plugins, themes, and core — **without modifying any of your site's files**. When a plugin or theme you use has a known security flaw, the WAF blocks attempts to exploit it, giving you time to apply the real update. ::: tip Note -The Web Application Firewall (virtual patching) described below requires the Imunify Security WordPress plugin (`imunify-wp-security`) `wp-3.0.1-2` or later, together with a supported Imunify agent — ImunifyAV/AV+ (`imunify-antivirus`) `av-8.7.1-2` or later, or Imunify360 (`imunify360-firewall`) `8.12.5-3` or later. - This WordPress WAF is a separate layer from the server-side [WAF (ModSecurity)](/dashboard/#waf-settings) and from [WordPress Account Brute-force Protection](/dashboard/#wordpress-account-brute-force-protection). It runs inside the WordPress plugin and focuses on blocking exploit attempts against vulnerable plugins and themes. In the Imunify control panel it is presented on the _CMS WAF_ tab. + +The feature needs a recent version of the plugin and of the Imunify software on the server. Your hosting provider manages both — see [Requirements](/wordpress_plugin/hosting_providers/#requirements). ::: ### How it works @@ -136,64 +141,53 @@ Use _Show more results_ to open the full incide ### Managing WAF incidents -The _CMS WAF_ tab in the Imunify control panel is where you review WAF activity and manage rules. - -::: tip Note -The _CMS WAF_ tab appears only when the WordPress WAF is enabled and the account has at least one WordPress site. -::: +Open the Imunify Security page from the WordPress admin menu to review WAF activity and manage rules. Everything on this page applies to the site you are currently in. #### Incidents -The _Incidents_ sub-tab lists every request the WAF acted on: +The _Incidents_ tab lists every request the WAF acted on: | Column | Description | |---|---| | _Date_ | When the incident occurred (newest first by default). | -| _Domain_ | The WordPress site that was targeted. | | _IP_ | Source IP address. Click it to filter the list by that IP. | | _Country_ | Country the IP resolves to. | | _Count_ | How many times the incident repeated. | | _Severity_ | Severity of the matched rule (0–3 low, 4–6 medium, 7–10 high). | | _Rule_ | The rule that matched. When it references a CVE, it links to the CVE record. | -You can filter incidents by date range and domain, or search by rule, description, or IP. Click a row to expand it and see the _Sensor_, _Rule_, _Abuser_ (source IP), and _Domain_ details. +You can filter incidents by date range, or search by rule, description, or IP. Click a row to expand it and see the _Sensor_, _Rule_, and _Abuser_ (source IP) details. ![](/images/wordpress-plugin/cms-waf-incidents.png) -*The Incidents sub-tab on the CMS WAF tab.* +*The Incidents tab.* #### Disabling a rule -If a WAF rule interferes with legitimate traffic, you can disable it. On the _Incidents_ sub-tab, click _Disable rule_ for the incident and confirm in the dialog: - -* By default, the rule is disabled for **all** of your domains. -* If you manage more than one WordPress site, you can instead pick specific domains from the _Select domains_ list. - -Click _Yes, disable_ to confirm. The change may take a few minutes to take effect across your sites. +If a WAF rule interferes with legitimate traffic, you can disable it. On the _Incidents_ tab, click _Disable rule_ for the incident, then click _Yes, disable_ to confirm. The rule is turned off for your site. The change may take a few minutes to take effect. Disable rule confirmation modal -*Disabling a WAF rule for all domains or for selected domains.* +*Confirming that a WAF rule should be disabled.* #### Disabled Rules -The _Disabled Rules_ sub-tab lists the rules you have turned off, showing the affected _Component_, _Version_, _Rule_, and _Domains_. To turn a rule back on, click _Enable_ and confirm. +The _Disabled Rules_ tab lists the rules you have turned off, showing the affected _Component_, _Version_, and _Rule_. To turn a rule back on, click _Enable_ and confirm. ![](/images/wordpress-plugin/cms-waf-disabled-rules.png) *Re-enabling a previously disabled rule.* -### Enabling or disabling the WAF +### Turning the WAF on or off -The WordPress WAF requires the Imunify Security plugin to be installed, and is controlled from _Settings_ | _General_ | _WordPress plugin_ in the Imunify control panel: - -* **Server administrators** enable or disable the WAF server-wide, and can choose whether it is on by default for new hosting accounts. See [WordPress plugin settings](/dashboard/#wordpress-plugin) and the [command-line reference](/command_line_interface/#wordpress-plugin). -* **Hosting-account owners** can turn the WAF off for their own account, unless the administrator has locked it server-wide (shown as *This value is set by server administrator*). +Your hosting provider decides whether the WAF runs on the server, and can turn it on or off for individual hosting accounts. If you need it changed for your site, contact your provider. See [Web Application Firewall](/wordpress_plugin/hosting_providers/#web-application-firewall) in the hosting provider guide. ## AI Bot Management Imunify Security includes **AI Bot Management** — a layer that identifies automated traffic (search-engine crawlers, AI/LLM crawlers, scrapers, and malicious bots) *before WordPress finishes loading* and applies a per-minute request limit to each kind of bot, while leaving real visitors untouched. It protects sites from aggressive crawling and bot-driven resource abuse — increasingly from the wave of AI training and scraping crawlers — without slowing down legitimate users. ::: tip Note -AI Bot Management requires the Imunify Security WordPress plugin (`imunify-wp-security`) `wp-4.0.2-2` or later, together with a supported Imunify agent — ImunifyAV/AV+ (`imunify-antivirus`) `av-8.8.3-6` or later, or Imunify360 (`imunify360-firewall`) `8.13.6-6` or later. It is a separate layer from the server-side [WAF (ModSecurity)](/dashboard/#waf-settings), from [WordPress Account Brute-force Protection](/dashboard/#wordpress-account-brute-force-protection), and from the plugin's own [Web Application Firewall](#web-application-firewall-virtual-patching). In the WordPress dashboard it appears as _Bot Protection_. +AI Bot Management is a separate layer from the server-side [WAF (ModSecurity)](/dashboard/#waf-settings), from [WordPress Account Brute-force Protection](/dashboard/#wordpress-account-brute-force-protection), and from the plugin's own [Web Application Firewall](#web-application-firewall-virtual-patching). In the WordPress dashboard it appears as _Bot Protection_. + +The feature needs a recent version of the plugin and of the Imunify software on the server. Your hosting provider manages both — see [Requirements](/wordpress_plugin/hosting_providers/#requirements). ::: ### How it works @@ -260,7 +254,7 @@ If your site cannot reach itself over HTTP, the pane shows a _Bot Protection_ row does not appear. Providers control it from the command line — see the [configuration file reference](/config_file_description/) (`ai_bot_protection`, `ai_bot_protection_preset`) and the [command-line reference](/command_line_interface/#wordpress-plugin). +1. **Hosting provider (server-wide).** The provider enables the feature and sets the default preset. When it is off at the server level, the _Bot Protection_ row does not appear. See [AI Bot Management](/wordpress_plugin/hosting_providers/#ai-bot-management) in the hosting provider guide. 2. **Site owner (WordPress admin).** Once the provider has enabled it, the WordPress administrator turns it on or off for their own site and chooses the preset from the _Bot Protection_ widget. 3. **`wp-config.php` (advanced).** Definitions in `wp-config.php` override the widget: @@ -277,3 +271,114 @@ define( 'IMUNIFY_AI_BOT_PROTECTION_PRESET', 'strict' );
When AI Bot Management is disabled in `wp-config.php`, the widget shows _Disabled in wp-config.php_ and the controls are locked. + +## Frequently asked questions + +### Why did the Imunify Security plugin appear on my site? I did not install it + +Your hosting provider installed it for you. The Imunify security software on the server adds the plugin to the WordPress sites it protects, so you get the security information of your site inside the WordPress dashboard. It is part of your hosting plan, not something you bought or downloaded. + +### Why is the plugin not in the WordPress.org plugin directory? + +The plugin only works together with the Imunify software running on the hosting server, so it is delivered by that software instead of the public directory. This is also why it is updated automatically, without an update notice in WordPress. + +### Do I have to pay extra for the plugin? + +No. It is included in the Imunify security service your hosting provider already runs. Some features depend on which Imunify product your provider uses — see [Protection modes](#protection-modes-enabled-vs-monitoring). + +### Can I deactivate or delete the plugin? Will it come back? + +Yes, you can deactivate or delete it like any other WordPress plugin. + +Deleting it also removes the data it stored for your site. A job on the server does this clean-up once a day, so it can take up to 24 hours. The same job records that you removed the plugin, so the server does not install it again by itself. + +If you want the plugin back later, ask your hosting provider — they can restore it for your site. + +Deactivating or deleting the plugin turns off the protection it provides inside WordPress — the [Web Application Firewall](#web-application-firewall-virtual-patching) and [AI Bot Management](#ai-bot-management) stop working for your site. Malware scanning on the server continues, but you no longer see the results in your WordPress dashboard. + +### Does the plugin slow down my website? + +The plugin is built to keep the work inside WordPress small: + +* Malware scanning runs on the server, not inside WordPress. +* The Web Application Firewall only loads rules for the plugins, themes, and WordPress version you actually have installed. +* The bot check runs before the rest of WordPress loads. It costs very little compared to building the page for that visitor, so every request it blocks saves your site far more work than the check itself uses. + +### Do I still need my other security plugin? + +Imunify Security does not replace a general-purpose security plugin, and it does not require you to remove one. It adds protection layers that run on the hosting server and inside WordPress. If you run another security plugin, both may report the same event, so check both before you decide something is wrong. + +### Does the plugin work on a WordPress multisite network? + +Multisite is only partly supported today, and it has not been fully tested. Some features may not behave as described on a multisite network, so do not rely on the plugin as your only protection there. + +### Where do I manage the settings? + +It depends on the setting: + +* In the **WordPress dashboard**, the Imunify Security widget shows the security status, and lets WordPress administrators change [AI Bot Management](#ai-bot-management) for the site. +* On the **Imunify Security page** in the WordPress admin menu, you review WAF incidents and disable individual rules for your site. See [Managing WAF incidents](#managing-waf-incidents). +* Some settings are controlled on the server and cannot be changed from WordPress. If a control is missing or locked, see [Why do I not see the Web Application Firewall or Bot Protection in the widget?](#why-do-i-not-see-the-web-application-firewall-or-bot-protection-in-the-widget). + +### What information does the plugin send? + +The plugin reads the security information of your site from the Imunify software running on the same server, over a local connection that does not leave the machine. It does not send your site's files, database, or page content anywhere. + +To keep protection current, it downloads updated data, such as the list of known crawlers used by [AI Bot Management](#ai-bot-management). + +Imunify also collects security information from your site to improve protection: + +* **WAF incidents** — the exploit attempts the [Web Application Firewall](#web-application-firewall-virtual-patching) acted on. A record includes the rule that matched, the IP address the request came from, and partial details of the request. +* **Traffic classification summary** — once a day, how much traffic fell into each bot category, together with the 50 most active IP addresses per category. This data is used only to make the classification more accurate and to identify sources that abuse sites. + +If your hosting provider has enabled error reporting, technical error reports may also be sent to Imunify. + +### A visitor to my site got an error page. What happened? + +Two protections can refuse a request: + +* HTTP 429 (Too Many Requests) — AI Bot Management refused a request from an automated client that went over its per-minute limit. Real visitors are never rate-limited. +* HTTP 403 (Forbidden) — either the Web Application Firewall matched the request against a known vulnerability in a plugin, theme, or WordPress core, or AI Bot Management blocked a client that kept sending requests after it was already refused with HTTP 429. See [Managing WAF incidents](#managing-waf-incidents) to check what the WAF blocked and why. + +### A WAF rule blocks legitimate traffic. How do I stop it? + +Open the Imunify Security page in the WordPress admin menu, go to the _Incidents_ tab, find the incident, and click _Disable rule_. The rule is turned off for your site — there is no list of domains to choose from, because the page only covers the site you are in. The change may take a few minutes to take effect. + +If the traffic is still blocked, wait a few minutes and clear any page or object cache your site uses, then try again — the old response may still be cached. If it keeps being blocked after that, ask your hosting provider. + +### Bot Protection blocks something I need. How do I stop it? + +Real visitors are never rate-limited, but a tool that calls your site — an uptime monitor, a backup or SEO service, or a plugin that fetches pages — is an automated client, so it can be refused with HTTP 429. + +Open the _Bot Protection_ row in the Imunify Security dashboard widget and choose one of these: + +* **Switch to a softer preset.** Click _change_, pick a preset, and click _Save_. _Monitor only_ still classifies traffic but does not block or limit anything, which is the quickest way to confirm that Bot Protection is the cause. +* **Turn protection off for this site.** The row has a switch that disables Bot Protection for your site only. You can turn it back on at any time. + +See [Turning it on or off](#turning-it-on-or-off) for the `wp-config.php` settings that override the widget, and [Protection presets](#protection-presets) for what each preset allows. + +If the _Bot Protection_ row is missing, see the next question. If the controls are locked, the feature is set in `wp-config.php` — see [Turning it on or off](#turning-it-on-or-off). + +### Why do I not see the Web Application Firewall or Bot Protection in the widget? + +A row is missing when the feature is not running for your site. There are two reasons for that: + +* **The software is older than the feature.** Both features need recent versions of the plugin and of the Imunify software on the server. See [Requirements](/wordpress_plugin/hosting_providers/#requirements) for the exact versions. +* **The feature is turned off** for the server or for your hosting account. + +Both are set on the server, so only your hosting provider can change them. + +### The widget says my site cannot reach itself. What does it mean? + +WordPress needs to be able to open its own address over HTTP to run scheduled tasks. When it cannot, scheduled tasks — including automatic updates of the bot data — may not run. This is usually caused by a local DNS or firewall setting on the server. Report it to your hosting provider, then click _Re-check_. + +### Something is not working. What can I do? + +Most of what site owners run into can be fixed from the WordPress dashboard, without any help: + +* A visitor got an error page — see [A visitor to my site got an error page](#a-visitor-to-my-site-got-an-error-page-what-happened). +* A WAF rule blocks legitimate traffic — you can disable that single rule for your site. See [A WAF rule blocks legitimate traffic](#a-waf-rule-blocks-legitimate-traffic-how-do-i-stop-it). +* Bot Protection blocks a tool you use — you can switch to a softer preset, or turn it off for your site. See [Bot Protection blocks something I need](#bot-protection-blocks-something-i-need-how-do-i-stop-it). +* A feature is missing from the widget — see [Why do I not see the Web Application Firewall or Bot Protection in the widget?](#why-do-i-not-see-the-web-application-firewall-or-bot-protection-in-the-widget). + +A few things are set on the server, and only your hosting provider can change them: enabling a feature for your hosting account, restoring the plugin after you delete it, and anything about malware found outside your WordPress files. diff --git a/docs/wordpress_plugin/hosting_providers/README.md b/docs/wordpress_plugin/hosting_providers/README.md new file mode 100644 index 00000000..394ef34e --- /dev/null +++ b/docs/wordpress_plugin/hosting_providers/README.md @@ -0,0 +1,234 @@ +--- +title: 'Imunify Security Plugin for WordPress: Hosting Provider Guide' +description: How hosting providers and server administrators install the Imunify Security plugin for WordPress, check a rollout, and control its Web Application Firewall and AI Bot Management. +--- + +# Hosting Provider Guide + +[[toc]] + +::: tip Are you a WordPress site owner? +This page is written for **hosting providers and server administrators**. It covers requirements, installation on your servers, and the settings you control. + +If you manage a WordPress site and want to know what the plugin does and what you can change in the WordPress dashboard, see the [Site Owner Guide](/wordpress_plugin/). +::: + +## Overview + +The **Imunify Security plugin for WordPress** brings the protection your Imunify product already provides into the WordPress dashboard of every site on your servers. It is available to all Imunify customers (ImunifyAV, ImunifyAV+, and Imunify360). + +For your customers, the plugin: + +* shows the security status of their site, including malware detected and cleaned; +* adds a **Web Application Firewall (virtual patching)** that blocks attempts to exploit known vulnerabilities in plugins, themes, and WordPress core; +* adds **AI Bot Management**, which rate-limits crawlers, scrapers, and AI bots; +* gives ImunifyAV and ImunifyAV+ users an upgrade path to Imunify360. + +The plugin is not published in the WordPress.org plugin directory. It is delivered and updated by the Imunify agent on the server. + +For what your customers see and can change themselves, send them to the [Site Owner Guide](/wordpress_plugin/). + +## Requirements + +**On each WordPress site:** + +* **WordPress version**: 5.0.0 or higher +* **PHP version**: 5.6 or higher + +**On the server:** + +* Imunify360 `8.4.1` or higher, or +* ImunifyAV/AV+ `8.6.0` or higher + +Individual features need newer versions of both the plugin and the Imunify agent: + +| Feature | Plugin (`imunify-wp-security`) | Imunify360 (`imunify360-firewall`) | ImunifyAV/AV+ (`imunify-antivirus`) | +|---|---|---|---| +| Base plugin (dashboard widget, plugin page) | — | `8.4.1` | `8.6.0` | +| [Web Application Firewall](#web-application-firewall) | `wp-3.0.1-2` | `8.12.5-3` | `av-8.7.1-2` | +| [AI Bot Management](#ai-bot-management) | `wp-4.0.2-2` | `8.13.6-6` | `av-8.8.3-6` | + +The plugin is updated by the Imunify agent, so keeping the agent current is enough. + +::: warning +WordPress multisite networks are only partly supported and have not been fully tested. Some features may not behave as documented on multisite. +::: + +## Installing the plugin + +Installation is a single server-wide switch. Once it is on, the plugin is installed in the background on every active WordPress installation on the server, and new WordPress sites are picked up by the daily job that scans for them. + +### From the control panel + +1. Navigate to Imunify settings in your hosting control panel (e.g., cPanel). +2. Open the `General` tab. +3. Scroll to the `WordPress Plugin` section. +4. Tick the `Install WordPress plugin` checkbox and click `Save changes`. + +![](/images/wordpress-plugin/panel-settings.png) + +*Plugin installation settings in the control panel* + +### From the command line + +
+ +``` +imunify360-agent config update '{"WORDPRESS":{"security_plugin_enabled": true}}' +``` + +
+ +On ImunifyAV and ImunifyAV+, use `imunify-antivirus` instead of `imunify360-agent`. + +`security_plugin_enabled` is the master switch for the plugin, its Web Application Firewall, and AI Bot Management. Setting it to `false` removes the plugin from the sites again. + +See also [WordPress plugin settings in the admin interface](/dashboard/#wordpress-plugin). + +### Checking the result + +After a rollout, list the WordPress sites where the plugin is installed: + +
+ +``` +imunify360-agent wordpress-plugin list-sites +``` + +
+ +To check whether the WAF is on for each hosting account, and whether that comes from the server default or a per-account override: + +
+ +``` +imunify360-agent wordpress-plugin waf status +``` + +
+ +Both commands accept filters and paging — see the [command-line reference](/command_line_interface/#wordpress-plugin). + +### When a site owner removes the plugin + +A site owner can delete the plugin from their WordPress site like any other plugin. A daily job then records the site as removed by the user, cleans up the data kept for it, and stops managing it. The server does **not** install the plugin on that site again, and turning `security_plugin_enabled` off and on again does not bring it back. + +To put the plugin back on such a site, contact Imunify support for the steps. A command for this is planned for a future release. + +## Web Application Firewall + +The WordPress WAF provides virtual patching against known vulnerabilities (CVEs) in WordPress plugins, themes, and core, without modifying site files. In Imunify360 matching requests are blocked with HTTP 403; in ImunifyAV and ImunifyAV+ they are logged only. + +For how the WAF works and how site owners review incidents and disable individual rules, see [Web Application Firewall (Virtual Patching)](/wordpress_plugin/#web-application-firewall-virtual-patching). + +::: tip Note +This WordPress WAF is a separate layer from the server-side [WAF (ModSecurity)](/dashboard/#waf-settings) and from [WordPress Account Brute-force Protection](/dashboard/#wordpress-account-brute-force-protection). +::: + +### Server-wide settings + +In the control panel, the WAF is controlled from _Settings_ | _General_ | _WordPress plugin_: + +* _Enable WordPress WAF_ — turns the WAF on for WordPress sites on this server. When it is disabled, WAF rules are removed from all sites, and site owners no longer see the WAF views in WordPress. +* _Enable WAF for new accounts by default_ — automatically enables the WAF for newly created hosting accounts. + +WordPress plugin settings in the control panel: Install WordPress plugin, Enable WordPress WAF, and Enable WAF for new accounts by default + +The same settings from the command line: + +
+ +``` +imunify360-agent config update '{"WORDPRESS":{"waf_enabled": true}}' +imunify360-agent config update '{"WORDPRESS":{"waf_default": true}}' +``` + +
+ +::: tip Note +The WAF is enabled by default for hosting accounts that already existed when it was first rolled out. Newly created accounts follow the _Enable WAF for new accounts by default_ setting. +::: + +### Per-account settings + +Change the WAF for hosting accounts in bulk: + +
+ +``` +imunify360-agent wordpress-plugin waf set --status enabled --all-users +imunify360-agent wordpress-plugin waf set --status disabled --users user1 user2 +``` + +
+ +Or for a single account: + +
+ +``` +imunify360-agent config update --user user1 '{"WORDPRESS":{"waf_enabled": false}}' +``` + +
+ +For all options, and for enabling or disabling individual WAF rules server-side, see the [WordPress plugin CLI commands](/command_line_interface/#wordpress-plugin). + +## AI Bot Management + +AI Bot Management classifies incoming traffic (verified search engines, verified AI crawlers, unknown automated clients, unverified bots, malicious bots, and humans) before WordPress finishes loading, and applies a per-minute request limit to each non-human category. Human visitors are never rate-limited, and the check is fail-open. + +For the categories, the preset limits, and what site owners see, see [AI Bot Management](/wordpress_plugin/#ai-bot-management). + +### Server-wide settings + +AI Bot Management is controlled through configuration keys rather than the control panel. Enable or disable it server-wide: + +
+ +``` +imunify360-agent config update '{"WORDPRESS":{"ai_bot_protection": true}}' +imunify360-agent config update '{"WORDPRESS":{"ai_bot_protection": false}}' +``` + +
+ +Set the default preset applied to sites that have not chosen their own — one of `balanced`, `strict`, or `monitor`: + +
+ +``` +imunify360-agent config update '{"WORDPRESS":{"ai_bot_protection_preset": "strict"}}' +``` + +
+ +While the feature is off server-wide, the _Bot Protection_ row does not appear in the WordPress dashboard widget. + +### Per-site control + +AI Bot Management is a server-wide setting. Unlike the WAF, it cannot be enabled or disabled for a single hosting account. Once it is on for the server, control belongs to the site: + +* the WordPress administrator turns it on or off for their own site, and picks a preset, from the _Bot Protection_ row of the dashboard widget; +* setting `IMUNIFY_AI_BOT_PROTECTION` or `IMUNIFY_AI_BOT_PROTECTION_PRESET` in the `wp-config.php` file overrides the widget. + +See [Turning it on or off](/wordpress_plugin/#turning-it-on-or-off). + +## What site owners can change + +| Setting | Controlled by you | Site owner can override | +|---|---|---| +| Plugin installed (`security_plugin_enabled`) | Server-wide | A site owner can delete the plugin from their site manually. It does not come back — see [When a site owner removes the plugin](#when-a-site-owner-removes-the-plugin). | +| Web Application Firewall | Server-wide and per hosting account | The hosting account owner can turn it off for their own account, unless you have locked it server-wide. The setting then shows *This value is set by server administrator*. | +| AI Bot Management | Server-wide only | Yes — the WordPress administrator turns it on or off for their own site from the widget. Setting `IMUNIFY_AI_BOT_PROTECTION` in the `wp-config.php` file overrides both. | +| AI Bot Management preset | You set the server default | Yes — from the widget, or by setting `IMUNIFY_AI_BOT_PROTECTION_PRESET` in the `wp-config.php` file. | +| Individual WAF rules | You can disable rules server-side | A site owner can disable a rule for their own site from the Imunify Security page in WordPress. | + +Site owners can solve most common problems themselves. The Site Owner Guide covers them in [Something is not working. What can I do?](/wordpress_plugin/#something-is-not-working-what-can-i-do) — blocked traffic, a WAF false positive, and Bot Protection refusing a tool they use. You can link to it from your own help pages. + +## Reference + +* [WordPress plugin settings in the admin interface](/dashboard/#wordpress-plugin) +* [WordPress plugin CLI commands](/command_line_interface/#wordpress-plugin) +* [Configuration file: WORDPRESS section](/config_file_description/) +* [Site Owner Guide](/wordpress_plugin/) diff --git a/scripts/generate-llms-txt.js b/scripts/generate-llms-txt.js index 74e12e31..6bb6e236 100644 --- a/scripts/generate-llms-txt.js +++ b/scripts/generate-llms-txt.js @@ -65,6 +65,17 @@ const getMarkdownTitle = async (filePath) => { if (lines[0] === "---") { const endIndex = lines.findIndex((line, i) => i > 0 && line === "---"); if (endIndex !== -1) { + // A frontmatter title is the full page title; the first heading may be a + // shorter in-page one. + const titleLine = lines + .slice(1, endIndex) + .find((line) => /^title:\s*/.test(line)); + if (titleLine) { + return titleLine + .replace(/^title:\s*/, "") + .trim() + .replace(/^['"]|['"]$/g, ""); + } startIndex = endIndex + 1; } } @@ -134,7 +145,11 @@ const buildLlmsTxt = async () => { const heading = doc.title; const docRoute = normalizeRouteKey(doc.link); const sidebarEntry = normalizedSidebar.get(docRoute) || []; - const sidebarRoutes = sidebarEntry.flatMap((entry) => entry.children || []); + // A sidebar child is either a route string, or a ["route", "Sidebar label"] + // pair used to give the sidebar a shorter label than the page title. + const sidebarRoutes = sidebarEntry + .flatMap((entry) => entry.children || []) + .map((child) => (Array.isArray(child) ? child[0] : child)); const orderedRoutes = sidebarRoutes;