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:
- Create ASN KB records in Shrewdies Resources for Approved and Controlled ASNs
- Create ASN posts and comments in Shrewdies Resource Blog for suspicious ASNs and for potential approved ASNs
- Add Wordfence warning, or other evidence of bad behaviour to blogs/KB, as they arise. Where appropriate, inform abuse email/form.
- Review ASN resources blogs at least daily. Where decisions can be taken, create CloudFlare and Shrewdies Resources records, then close discussions with appropriate links.
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:
- Add any domains not currently on CloudFlare to try increase rule limit.
- 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
- Helpdesk support agent gets ASN for suspect IP
- Helpdesk support agent posts Wordfence warning in Shrewdies Resource blog (or knowledgebase) for ASN
CloudFlare Validated IP Whitelist Candidate Procedure
- Helpdesk support agent gets ASN for valid user IP
- 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:
- Action the CloudFlare Migration Plan
- Reap the CloudFlare Migration Rewards
- Appreciate my CloudFlare Migration improvements
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.