CloudFlare is vital to my online network. On Saturday, a Denial of Service attack on GoutPal broke my CloudFlare account.

This is a technical issue. However, rather than write about it at Shrewdies, I’m questioning CloudFlare here first. I’ve got to make a decision about CloudFlare. It’s personal to me. I want to get this right so I can advise other people properly.

CloudFlare is complicated. Much of the support knowledgebase is very technical. I can’t understand it all, but I need to understand enough to make the right decisions about using CloudFlare to protect and improve my website collection.

The problem I encountered yesterday is:
CloudFlare has limits on the number of firewall rules. Their best recommendation to date is to raise the limit by throwing money at the problem. I don’t have money at the moment, so I have to use CloudFlare in different ways now, or move to an alternative. I am only prepared to commit money in the long term if I can understand exactly how that improves the current restriction.

An hour of research has revealed to me that there is no direct alternative to CloudFlare. There might be ways of achieving the same benefits, but that would involve spending a lot of time investigating Incapsula and running a migration project. I do not have the time now to manage such a project. Therefore, I will stay with CloudFlare. But, now I must decide how to change my CloudFlare administration processes.

I believe the best approach is to use ASN as the main limiter for CloudFlare Website Firewall rules. This should be balanced with Whitelist rules for valid human IPs and approved ASNs. Country records should probably be ignored. No IP CIDR records should exist, unless these can be inferred from traffic analysis. Suspicious IPs should be discussed before ASN action is taken. Discussion will be partially in Shrewdies forum, but mainly as blog posts in Shrewdies Resources. I’m starting with Shrewdies Resources blog postings to avoid cluttering the forum with lots of admin reports. This may change once the majority of ASNs have been added to the Shrewdies Resource knowledgebase (KB).

Outline procedure for suspicious/valid IPs is:

  1. Create ASN KB records in Shrewdies Resources for Approved and Controlled ASNs
  2. Create ASN posts and comments in Shrewdies Resource Blog for suspicious ASNs and for potential approved ASNs
  3. Add Wordfence warning, or other evidence of bad behaviour to blogs/KB, as they arise. Where appropriate, inform abuse email/form.
  4. Review ASN resources blogs at least daily. Where decisions can be taken, create CloudFlare and Shrewdies Resources records, then close discussions with appropriate links.
CloudFlare Explosion image

CloudFlare exploded with too many firewall rules.

Why am I migrating CloudFlare?

In true PROSPRA fashion, the Purpose of this CloudFlare project is:
I will choose between migrating my CloudFlare account to a new clean account, or changing my existing Website Firewall Rules to suit the restrictions imposed by CloudFlare.
That was the original working Purpose as I wrote this plan. As expected, during analysis of Objectives, I refined my Purpose Statement to be:
I will gradually move existing firewall records from predominantly IP based to predominantly ASN based. I will use Shrewdies Resource Knowledgebase to facilitate this, and revise security routines accordingly. I anticipate ongoing content increase from ASN discussion and recommendations, with one-off content growth from documenting this project.

CloudFlare Migration Reality Check

The resources required are time. The project rewards are improved security for all websites in my protected collection. To justify the time spent, I need to publish valuable content as secondary rewards. Content includes:

  • Shrewdies Resources blog for ASN discussion prior to KB inclusion. Organise by country, distinguishing between hosting, access, and mixed ISPs.
  • Shrewdies Resources KB for hosting/access companies by ASN.
  • Shrewdies Resources KB for resources used in this CloudFlare Migration project.
  • Shrewdies Forum posts for relevant technical challenges.
  • Shrewdies Guide posts for website protection services.

CloudFlare Migration Objective Choices

CloudFlare Migration choices are:

  • Start a new CloudFlare account and migrate websites to it one-by-one
  • Remove all current Website Firewall rules and rebuild
  • Gradually change existing Website Firewall rules within CloudFlare limits.

All websites are protected individually through Wordfence. The admin benefit comes from sharing Wordfence blocks across all sites. CloudFlare is better than Wordfence alone, as it saves significant bandwidth, and provides CDN. That begs the question of Wordfence providing similar DNS services to rival CloudFlare. Not likely in near future, so best ignored for now.

1. Gradual CloudFlare Migration Option

Though gradual is usually best, there are significant tasks to redo in the setup. Especially, VigLink is tied to CloudFlare, so would need transitioning.

2. Sudden CloudFlare Restart Option

Relies on checking with CloudFlare if this is possible. Advantage is all new records can integrate with new IP management processes. Disadvantage is that losing existing IP protection will create many more warnings to process.

3. Gradual CloudFlare Rule Change Option

Advantage is less disruption to current protection, which is mostly effective. Disadvantage is extra processing time identifying firewall records that need to be changed.

CloudFlare Migration Selected Strategy

The obvious choice is gradual rule change rather than any form of migration or total restart. This requires:

  • Total removal of CIDR and country records (513 /16 CIDR, 3880 /24 CIDR, 39 countries).
  • Selective removal of individual IP records.
  • Creation of Shrewdies Resources pages for ASN records
  • Creation of Resource blogs for IP records not linked to existing ASN

This requires transition routines for Shrewdies admin:

  1. Add any domains not currently on CloudFlare to try increase rule limit.
  2. Use CloudFlare Traffic report to log details of suspicious IPs similar to new procedure below. Ignore JavaScript challenges as these have been migrated (as next step).
  3. Change existing ASN rule to link to forum/resource page, and change from CAPTCHA to JavaScript Challenge. Delete any related individual IP and CIDR records.
  4. Delete IP range records: approx daily rate = 1 Country. When countries cleared, review number of old records remaining, and start deleting CIDR, ASN(CAPTCHA), and individual IPs.

I will develop admin routines for each source of IP records. Sources include:

  • Wordfence blocked login tickets. This is currently the main source of suspects.
  • Wordfence user login tickets. This is currently the main source of valid IPs to Whitelist
  • Redirection 404 logs.
  • Wordfence Throttle Log.
  • Wordfence Live Traffic and Firewall review.
  • CloudFlare Traffic Review

For the purpose of this project, I will focus on blocked login attempts and user logins. I will document other sources during the Appreciation step in this project.

CloudFlare Suspicious IP Blocked Login Procedure

  1. Helpdesk support agent gets ASN for suspect IP
  2. Helpdesk support agent posts Wordfence warning in Shrewdies Resource blog (or knowledgebase) for ASN
  3. Shrewdies admin reviews IPs. When new firewall rules can be created, move topic to country page(s) in resources, and create ASN. ASNs should be JavaScript Challenge, with note linking to Shrewdies Resource.

CloudFlare Validated IP Whitelist Candidate Procedure

  1. Helpdesk support agent gets ASN for valid user IP
  2. Helpdesk support agent posts anonymous user details in new or existing topic for ASN

CloudFlare Rule Change Followup

I’ll report back (here or in Shrewdies) as I:

  1. Action the CloudFlare Migration Plan
  2. Reap the CloudFlare Migration Rewards
  3. Appreciate my CloudFlare Migration improvements

One potential improvement is to use Country records when under attack. Set country to JavaScript Challenge for duration of attack, then change to Whitelist.

I’ve used this blog to collect my thoughts on this important problem. I intend to formalise this project through a PROSPRA project in Shrewdies forum.

Posted by Keith Taylor

I am the owner of this website, which is part of my Keith Charlie Taylor Internet Community. My Community Profiles are:Keith at GoutPal Gout Help.Full bio, and more, at Keith Taylor Internet Help Stories. Get in touch:Contact: Contact Keith Taylor Facebook: LinkedIn: LinkedIn Keith Taylor Twitter:


This article has 3 comments

Leave a Reply