I have used zero trust to protect my wordpress admin by requiring google authentication.
The problem is that the application configuration only allows me to give 1 specific URL.
So I can only block mydomain.com/wp-login.php
but I also need to block mydomain.com/wp-admin/* as well
Is there any way to do this other than to create a separate application for every URL ?
You can create one access policy per pattern, not necessarily per URL, depending on your need (Access policies match the provided pattern, no need to use *):
wp-admin
(with a bypass policy for wp-admin/admin-ajax.php, if needed)
wp-login.php
wp-json
(with a bypass policy for wp-json/..., as needed)
The alternative would be to create a pattern that match them all:
wp-
But then you’d still need to create a bypass policy for each needed exception, such as the ones above, plus:
wp-content
wp-includes
etc.
So i do have to create multiple applications for multiple patterns?
I don’t think blocking wp- would be good, prob will block loads of things it shouldn’t
Exactly. That’s why I suggested some bypass policies, though you may need others. Each WP installation has its own set of requirements. You should in most cases bypass wp-content and wp-includes as those are needed by the front end. As for wp-json, it all depends on whether your installation (the theme or some plugin(s)) is using the WordPress REST API. Etc., etc., etc.
If you need every file on your backend protected, I’d think so. That’s how I do it anyway. Beware that, once you put wp-admin under an access policies, some plugins may start complaining or stop working altogether when you visit the admin panel. The solution for this is to open Developer Tools (F12) and see in the console which file is being blocked, then open it on a separate tab. After you do this once, you should be good for the session.
ok this just seems way too clunky. It seems crazy that you can only use 1 pattern/URL per application, that’s not how applications work.
is this a limitation of the free plan, or is it the same on the paid plans?
This may be the lack of coffee talking—but within a Bypass policy, how does one add the path?
I get the message of Bypass policies set a path that Access will not protect. You can configure IP or group-based rules, or set the policy to permit all requests with “Everyone”., but I just don’t see the field.
Hi,
You add the path while creating/configuring a ZT Access application for your website.
In the next step, you’ll be asked about the policy for the application. You then set it to Bypass and define who to include (Everyone, IP, email etc).
The message about Access will not protect... is a standard warning. Of course it won’t protect, and that’s presumably what you want. Otherwise you wouldn’t be creating a Bypass policy. Keep in mind that this refers only to the ZT Access protection. Requests for the relevant path will still be subject to Cloudflare WAF and Firewall rules.
Ah, so you do in fact actually need to create an application per-path in order to do exceptions to a given Allow policy in others? If so, that’s quite counter-intuitive as Bypass policies can be created within a given application.
I might be understanding it wrong though!
It seems far more logical to me to add applications then paths then policies per path within a given application, just like within the main Cloudflare Dashboard you’ve got orgs > domains > then individual features per-domain in terms of hierarchy.
I totally agree. Counter-intuitive and confusing, as are the different rules applying to the use of wildcard *. Only at the application level you can set a path, so you need to add an “application” for each path pattern.
On the plus side, once setup, it works beautifully. Really impressed by the actual performance of it. Much more effective than leaning on Wordfence and wasting server resources on bots bruteforcing wp-admin. Love it.
I also have to totally agree! As a bonus, you can focus the scope of your Firewall Rules (aka WAF Custom Rules) on areas other than the ones covered by ZT. That reduces considerably your Cloudflare Security Event logs, which is really good in case you ever need to investigate/mitigate an attack.
yet a totally counterintuitive, illogical and confusing way of doing it.
Why on earth would you want to create multiple applications just to add more rules to the same application?
I was hoping to use this for all my clients, but don’t fancy having to go through that convoluted setup every time.
