Categories
Monitoring

Identify your StatusCake calls

If you’re considering monitoring your website using Statuscake, there are two potential issues you should be aware of. Firstly, Statuscake relies on virtual machine hoster on the internet, and their IP ranges may be impacted by DDoS mitigation efforts. This means that individuals from the same ASN or subnets may be involved in attacking your website. Once you start blocking providers of compute resources on the internet, your monitoring might start to become affected too and become flaky.

To work around this, you can refer to the official IP address list at Statuscake’s Knowledge Base and use it to selectively allow traffic from Statuscake. This is an alternative or can also be run in parallel with some additional benefits it might offer.

Using the IP address list might be cumbersome, as this IP address list requires regular updates. Also, every Statuscake instance is free to monitor, which might be undesirable. An easy way to prevent this is by adding a special ID to your user agent string.

https://app.statuscake.com/monitoring/uptime/***/edit (2024-04-21)

This is a complete example of what the user agent might look like for you.

Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake Tenant: H%k08YcSfkfC?NfaPp*wX+CKK)

This approach not only differentiates who is making queries with this monitoring tool but also allows for the blocking of requests from tenants who are not allowed.

This user agent can also be used as a marker to determine whether to throttle or block requests and, for example, still allow requests from your external monitoring while blocking all malicious traffic.

Custom HTTP Header

Arguably, you could also use a custom header for this purpose. However, with public cloud providers, it might be much harder to read or analyze those. Whereas the user agent string is commonly easy to record and analyze.

Is a pre-shared secret safe?

You need to protect this string since it functions as a pre-shared key. However, for an otherwise public website, this might not be a deal-breaker. It could simply provide a slight advantage in further securing your application without hindering your external monitoring provider.

Hosting, for example Azure FrontDoor WAF

On your hosting end, you can now start using this header information, for example, in the Azure Front Door Custom Rules to block under certain conditions, but not to block if this header is present, for instance.

https://portal.azure.com/*** (2024-04-21) WAF Policy Custom Rule

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.