[spacetime_cmplx]

That's concerning. Could you elaborate on how you identified the traffic as cloudflare workers? Also, what sorts of HTTP attacks? wp-admin probes? Plain DDoS?

Cloudflare has (had?) a murky history with not taking down DDoS for hire services ironically hosted behind cloudflare. But while you could argue they had an incentive to do that (sell protection), I can't think of any incentive to let Workers be abused.

[capableweb]

> Could you elaborate on how you identified the traffic as cloudflare workers?

Trivial based on the fact that HTTP requests coming from CloudFlare Workers has a cf-worker header. Also, any traffic coming from cloudflare-owned IP blocks clearly belongs to cloudflare and can be safely blocked.

[InvaderFizz]

On the second point, with the introduction of Cloudflare WARP VPN, that's not quite true. Additionally, I believe Safari Private Relay may end up looking like it originates from CF as well.

[ignoramous]

> Additionally, I believe Safari Private Relay may end up looking like it originates from CF as well.

Cloudflare reserves IP ranges just for Private Relay: https://developer.apple.com/support/prepare-your-network-for...

[KomoD]

> and can be safely blocked.

Well no, not if you yourself are also using Cloudflare

[Manouchehri]

You can block third party Workers with a CF WAF rule. Here's an example:

cf.worker.upstream_zone ne "" and not cf.worker.upstream_zone in {"aimoda.workers.dev" "ai.moda"}

[capableweb]

You mean like server<>server communication? Hopefully that communication stays within the network rather than going from server<>internet<>server

[KomoD]

I mean if you are using Cloudflare with their proxy, so origin<>cloudflare<>client

[capableweb]

Yeah, then you'd just block based on the client IP which is in a header, rather than the IP on the connection.