"Site24x7" WAF block ineffective

Greetings all,

Recently, we’ve seen an uptick in automated/bot traffic to our domain. This is both noticable in the Cloudflare Dashboard, and in our webserver’s logs. We’ve taken steps to mitigate this, and for the most part, our efforts have been fairly effective.

That is, against all but one: 136.143.176.51, a ZOHO IP requesting our site in a HEAD request, with a user-agent of “Site24x7”. We added the ASN to our master WAF block rule, but when that proved ineffective, we also added the user-agent and request method to the rule – also to no avail. We then created a separate rule to specifically block the IP address, but the requests continue to pour in every 10 minutes.

Here’s a few entries from the logs, complete with ray IDs in the event there’s an interested employee out among the clouds:

136.143.176.51 | [27/May/2024:13:38:29 -0400] "HEAD / HTTP/1.1" "-" 200 | 0 Bytes "Site24x7" | CF-Ray: 88a7c7641c2130ab-SEA
136.143.176.51 | [27/May/2024:13:48:32 -0400] "HEAD / HTTP/1.1" "-" 200 | 0 Bytes "Site24x7" | CF-Ray: 88a7d61c0f1d0923-SEA
136.143.177.51 | [27/May/2024:13:58:35 -0400] "HEAD / HTTP/1.1" "-" 200 | 0 Bytes "Site24x7" | CF-Ray: 88a7e4d38fe97c33-LAX
136.143.176.51 | [27/May/2024:14:08:38 -0400] "HEAD / HTTP/1.1" "-" 200 | 0 Bytes "Site24x7" | CF-Ray: 88a7f38f993276bc-SEA
136.143.176.51 | [27/May/2024:14:18:41 -0400] "HEAD / HTTP/1.1" "-" 200 | 0 Bytes "Site24x7" | CF-Ray: 88a80247d803c4d7-SEA
136.143.176.51 | [27/May/2024:14:28:45 -0400] "HEAD / HTTP/1.1" "-" 200 | 0 Bytes "Site24x7" | CF-Ray: 88a811079abbc73d-SEA
136.143.177.51 | [27/May/2024:14:38:48 -0400] "HEAD / HTTP/1.1" "-" 200 | 0 Bytes "Site24x7" | CF-Ray: 88a81fbd4cd57ed5-LAX

My initial thoughts here are that Cloudflare’s failing to block the HEAD method through WAF. I’ve also noticed other slips, including log entries of IP Access Rules permitting connections that should have been blocked by WAF – or logged incorrectly. For that conflict, I deleted the conflicting IP Access Rule, but figured it was worth the mention.

In the end, I’m uncertain what to think here. Could this be a caching flaw, or has this service found some means of bypassing Cloudflare’s firewalling, ignoring the customer’s desire to block said traffic? What I can say is that we have no affiliation with Site24x7 and have not consented to their monitoring.

Thanks all.

Do you have any rules that allow Cloudflare verified bots? As this is one…
https://radar.cloudflare.com/traffic/verified-bots

1 Like

I do not, no. As far as I am able to tell, based on the newer and harder to navigate Cloudflare dashboard, I am not permitting bot traffic of any kind and have no settings enabled to allow them.

1 Like

Following up after digging into it the last few hours, so that this doesn’t become an XKCD #979.

Turns out, it was a separate domain we host that I’d forgotten about. It’s also protected by CF, but through a separate account. With the way nginx structures it’s default logs, I had assumed $http_referer’s output of "-" in my logs meant my domain. In swapping it for $host, it began printing the culprit domain properly.

The more you know.
Thanks all.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.