Cloudflare Proxy for BBIS

Andrew Jordan

Hi everyone!

We are exploring Cloudflare as a proxy to our self-hosted giving pages (proxy, WAF, bot detection, etc.). We've seen Blackbaud documentation saying this isn't supported, but are wondering if it's possible. We'd like to:- Apply security rules only to the public giving paths- bypass any other page paths (cms, etc.) - disable caching (site-wide)- whitelist the payment provider (redirect to success page)

We'd love to hear from anyone currently running BBIS behind a Cloudflare proxy. Any other considerations and information would be greatly appreciated!

Thank you for your time!

Andrew

Bryce Howard

It is understandable for blackbaud to go with this not supported. There are too many variable and it has to be configured based off whatever you are using. Technically it's just https traffic and proxies, so it's possible. Giving flows depend on session cookies, anti-forgery tokens, and payment callbacks. If you have too aggressive waf or bot rules it will absolutely break things. It is hard to give specifics without knowing your specific configuration. I had a contract where the client ran everything though Cloudflare. This was a couple years ago and details are a bit hazy but generally -

• cloudflare has been moving people off the legacy page rules system to a newer family of rules (cache , config, waf rules). I'd recommend building everything in the new rules engine. cloudflare automated the old security level setting and locked it to aways protected in the dashboard. You can no longer set it manually unless you use the API or terraform config. This make notes and other guides that tell you to dial security level down for specific paths outdated . You scope security via waf custom rules now.
  • https://blog.cloudflare.com/enhanced-security-and-simplified-controls-with-automated-botnet-protection/
  • https://linuxblog.io/recommended-cloudflare-performance-security-settings-guide/
• Use the strictest tls mode that's compatible with your origin cert. Lock the origin firewall to only accept cloudflare's published ip ranges (otherwise anyone bypassing dns hits your origin direct), and pass the original host header through.
• Scoping security to giving paths and write waf custom rules whose match expression is restricted to your giving url path or hostname matching and apply the security action.
• Bypassing cms and admin paths is a "skip" rule that runs first, matches your admin/cms paths and tells cloudflare to skip the security features you don't want firing on those requests.
  • https://developers.cloudflare.com/waf/custom-rules/skip/
• Not everything is skippable through the rules engine. The basic bot fight mode toggle is not skippable and I think only super bot fight mode is.
  • https://developers.cloudflare.com/waf/custom-rules/skip/options/
• Disable caching with a cache rule whose expression matches your hostname/path and sets the cache action to bypass. Verify by inspecting response headers on a giving page. cloudflare returns a cf-cache-status header that tells you whether the edge served from cache or passed through to origin
  • https://developers.cloudflare.com/cache/how-to/cache-rules/
• The biggest thing I am uncertain about is whitelisting the payment provider, which I think is two separate problems. The redirect back to your success page after payment is the donor's browser following a redirect, not the payment processor's servers calling you. You handle that by url path where your return/thank-you url isn't getting challenged by your waf rules. The server side webhook/postback where the processor calls your site to record the gift is the one you whitelist by source IP combined with the webhook path, using a skip rule so cloudflare doesn't challenge or block that server to server call - I think.. again not even 80% sure on this part.
  • https://kb.blackbaud.com/knowledgebase/Article/50865
  • But I know the exact flow will depend on whether you're on blackbaud checkout bbps, or a 3rd party gateway as it matters where that traffic is routed.