WAF: Add a dedicated automatic-rules.php file for storing firewall rules

[nateweller]

This PR ensures that sites do not remove their automatic rules previously downloaded from WPCOM, in situations where the rules file is being re-generated and the site no longer has access to the latest firewall rules (i.e. cancelled their Scan plan).

Changes proposed in this Pull Request:

• Adds a new rules/automatic-rules.php file for storing automatic rules fetched from WPCOM.
• Updates the generation of rules/rules.php to require() the relevant rules files, based on the WAF configuration (automatic and manual rules enabled options).
• Updates the Protect plugin to allow users to toggle automatic rules when they have the free plan but an old copy of automatic-rules.php available to use.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

peb6dq-p2-m9

Does this pull request change what data or activity we track or use?

No

Testing instructions:

• Start with a Jetpack site with a Scan plan.
• Activate the WAF module and ensure the automatic-rules.php file is generated, but not yet included in the main rules.php file.
• Validate a ?test=<script> request is not blocked.
• Enable automatic rules.
• Validate a ?test=<script> request is blocked.
• Enable manual rules and update the IP allow/block list with an IP address you can test.
• Validate the relevant IP rules file is updated, along with the main rules.php file.
• Validate the IP is blocked/allowed.
• Disable automatic rules.
• Validate that the relevant IP rules file is not updated, but no longer required by the main rules.php file.
• Validate the IP is no longer blocked/allowed.
• Cancel your Jetpack Scan plan.
• Toggle the WAF module off and then on again.
• Validate that the automatic-rules.php file still contains the automatic rules fetched at the beginning of your testing.

Screenshots

When the site previously upgraded and fetched automatic firewall rules, and then downgraded back to the free plan:

[github-actions]

Are you an Automattician? You can now test your Pull Request on WordPress.com. On your sandbox, run bin/jetpack-downloader test jetpack add/waf-automatic-rules-file to get started. More details: p9dueE-5Nn-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ⚠️ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• 🔴 Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

🔴 Action required: Please add missing changelog entries for the following projects: projects/plugins/protect

Use the Jetpack CLI tool to generate changelog entries by running the following command: jetpack changelog add.
Guidelines: /docs/writing-a-good-changelog-entry.md

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Jetpack plugin:

• Next scheduled release: February 7, 2023.
• Scheduled code freeze: January 30, 2023.

---

Protect plugin:

• Next scheduled release: February 7, 2023.
• Scheduled code freeze: January 30, 2023.

[dkmyta]

With a fresh installation, using Protect, I was able to toggle the Automatic and Manual rules without any issue and the rules.php file was updated accordingly with requires for each of the corresponding allow-ip.php, block-ip.php, and automatic-rules.php files.

When canceling the plan, I could verify that the require for automatic-rules.php remained in the rules.php but that the content of the file was removed.

On the same install, via the Jetpack settings, the manual rules toggle handled similarly, however, regardless of the presence of a Scan plan, I was unable to get the automatic-rules.php require to apply when toggling the module.

[miguelxpn]

Maybe we should change the name? We have too many permutations of RULES_FILE naming and it's starting to get confused, maybe something like ENTRYPOINT_FILE?

[nateweller]

I've organized the constants a bit, and renamed them as follows via 70f04f4:

• RULES_ENTRYPOINT_FILE
• AUTOMATIC_RULES_FILE
• IP_ALLOW_RULES_FILE
• IP_BLOCK_RULES_FILE

This introduces a naming system where the sub-rule file are all named FOO_BAR_RULES_FILE while the main file is RULES_ENTRYPOINT_FILE for extra distinction.

[nateweller]

On the same install, via the Jetpack settings, the manual rules toggle handled similarly, however, regardless of the presence of a Scan plan, I was unable to get the automatic-rules.php require to apply when toggling the module.

I pulled in some backwards compatibility changes from #27785 to resolve this issue (d9ae22e and 0da59ac).

This PR is now ready for re-review 👍

[dkmyta]

When I first activated Protect on a fresh Jurassic Tube instance, the Firewall was disabled by default - after hitting the prompt to enable, the notice remained after the loading icon resolved, prompting me again to enable it until I refreshed the page. The WAF module did appear to be enabled on the initial click and the endpoints were registered, however, it seems that the latest changes may have introduced an issue with toggling the Automatic and Manual rules settings. The initial attempt presents an error notice, and an immediate second attempt succeeds. A refresh of the page on the initial attempt displays as if the settings are active, however, in either case (regardless of a plan), no rules file is generated, no rules are run, and we are unable to successfully save changes to the manual rules settings, although we can access them.

With the WAF module enabled and all other settings off, activating Jetpack produces the following fatal error because we never initially generated the rules file. It is not clear to me why Waf_Runner::deactivate is run since I was only enabling Jetpack, not deactivating Protect or any other WAF settings:

PHP Fatal error:  Uncaught Exception: Failed to empty rules.php file. in /usr/local/src/jetpack-monorepo/projects/packages/waf/src/class-waf-runner.php:403
Stack trace:
#0 /usr/local/src/jetpack-monorepo/projects/packages/waf/src/class-waf-initializer.php(54): Automattic\Jetpack\Waf\Waf_Runner::deactivate()
#1 /var/www/html/wp-includes/class-wp-hook.php(308): Automattic\Jetpack\Waf\Waf_Initializer::on_deactivation()
#2 /var/www/html/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
#3 /var/www/html/wp-includes/plugin.php(517): WP_Hook->do_action()
#4 /usr/local/src/jetpack-monorepo/projects/packages/status/src/class-modules.php(586): do_action()
#5 /usr/local/src/jetpack-monorepo/projects/plugins/jetpack/class.jetpack.php(592): Automattic\Jetpack\Modules->update_active()
#6 /usr/local/src/jetpack-monorepo/projects/plugins/jetpack/class.jetpack.php(601): Jetpack::update_active_modules()
#7 /usr/local/src/jetpack-monorepo/projects/plugins/jetpack/class.jetpack.php(2919): Jetpack::delete_active_modules()
#8 /usr/local/src/jetpack-monorepo/projects/plugins/jetpack/class.jetpack.php(2898): Jetpack::handle_default_module_activation()
#9 /usr/local/src/jetpack-monorepo/projects/plugins/jetpack/class.jetpack.php(2783): Jetpack::plugin_initialize()
#10 /var/www/html/wp-includes/class-wp-hook.php(308): Jetpack::plugin_activation()
#11 /var/www/html/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
#12 /var/www/html/wp-includes/plugin.php(517): WP_Hook->do_action()
#13 /var/www/html/wp-admin/includes/plugin.php(691): do_action()
#14 /var/www/html/wp-admin/plugins.php(58): activate_plugin()
#15 {main}
  thrown in /usr/local/src/jetpack-monorepo/projects/packages/waf/src/class-waf-runner.php on line 403

[nateweller]

@dkmyta Thanks so much for all of the testing and assistance on this PR!

I've updated with all of the latest changes from trunk/phase 2, and fixed the issues you were having. Now, the Protect UI will allow you to manage automatic rules after downgrading.

Ready for your re-review 🙏

[nateweller]

Note: Changelogger validity will be fixed in the add/protect-waf-phase-2 branch.

[dkmyta]

Works great!