from accessing my site, but is my only option to insert each ASN into the Firewall rules page? There are 700+ ASN’s there and this would take a crazy amount of time. Is there any way I can input the whole list into the firewall rules?
I’m not too experienced in coding/developing, would you happen to know an easy way for me to use the API to quickly block the ASN’s? Thank you for your time.
Just a side note, if your issue is bot traffic, this list will block out a large chunk of it but it won’t necessarily solve the underlying problem. The Bot Management solution will, without blocking real users.
From looking through that ASN list, we have seen the traffic be in excess of 98% bots/malicious traffic at times but it also does produce some good bots and legitimate users depending on your site. Think SEO bots, Amazon’s Alexa bot, etc.
If the traffic hits an API, you can’t challenge it like you can on your website so it’s all or nothing with blocks
Bot Management might be cost prohibitive but, if not, it solves the underlying issue without having to wholesale block ASN’s, IP’s, UA’s etc.
If you enter these into a FW rule, I’d def recommend separating them so it’s easier to search and find. Manually, using notepad and the syntax like @sandro mentioned works well. I’d just break into a few chunks, personally. Better visibility on the analytics side.
I second @dmcclure’s concern about over-blocking here.
The four kilobyte limit can be circumvented by having two rules. Of course an import to IP access rules would also work, however I still believe that would over-block and maintaining that list, respectively configuring exceptions, might be quite a hassle.
Overall I would not block 800 networks for no reason. Rely rather on Cloudflare’s own bot algorithms and block individual ASNs if they send too many requests.
This CF Firewall is capturing when bot management score is less than 6 = non-human. As you can see alot of the ASNs are from cloud hosting providers as they rent out their servers to bad bot operators etc.
I usually separate out known cloud hosting provider ASNs in a group and only apply their challenge/blocks to sensitive areas like login/registrations/contact pages if CF Bot Management isn’t available i.e. non-Enterprise plans. Afterall, there is little or no risk in preventing legit crawler/search bots from not crawling login/rego/contact pages but they’re often targets for brute force login/credential stuffing attacks from bots operated on cloud providers too.
There is a big difference between traffic from malicious bots that aren’t a part of a specific attack and targeted attack traffic, for sure. Having dealt with brute force and cred stuffing, blocking ASN’s isn’t a tenable solution. It’s like playing the old whack-a-mole game.
To a certain extent it is. I do block, respectively challenge ASNs as well, however that should be selective lists of ASNs which already proved to be an issue for the site not a one-size-fits-all list compiled by a random third party.
To minimize the hassle @sandro mentioned in maintaining a list like this, I’ve come to prefer an approach where, instead of:
If bad actor > block
I now use a combination of:
If bad behavior > Block
If not good actor > Challenge
You then have a much smaller list to maintain, and very few, if any, surprises on your origin server access logs.
A Firewall Rule expression for the fist part would look like:
(not cf.client.bot and not ip.geoip.country in {"AA" "BB" "CC"} and not http.request.uri.path in {"/ads.txt" "/robots.txt"} and not ip.src in {1.2.3.4 1.2.3.5} and not ip.geoip.asnum in {123 124 125})
where you’d exclude from the Captcha the countries where your target audience is, some special URLs (/ads.txt, /robots.txt etc, but also, if applicable a rule for hostname such as api.example.com), and the IPs and ASNs of services you depend on.
Then couple this rule with one mostly URL-based for bad behavior, such as:
(http.request.uri.path contains "wp-config") or (http.request.uri.path contains ".php" and http.request.uri.path contains "/wp-content/") or (http.request.uri.path contains "phpmyadmin") or (http.request.uri.path in {"installer.php" "installer-backup.php" "/te3/signup.php" "/assets/images/new_license.php" "/connectors/system/phpthumb.php" "/home/favicon.ico" "/2/favicon.ico" "/3/favicon.ico" "/view/img/favicon.ico"})
Every now and then you’d need to bypass a IP for certain online services to work. If you use these services all the time, you may want to insert the exception to the FR, otherwise just create a temp whitelist IP Access rule for the duration of the service.
Ya, depends on the use case. I’ve seen ASN’s get used that are very legitimate ASN’s; Charter, Comcast, various mobile carriers. It’s probably not an issue the OP needs to worry about. It’s something I’ve run into with targeted attacks and, while it might be fine for some websites to wholesale block, you can’t do it with a business. I had a customer whose call center would get overwhelmed if we blocked the wrong ASN, for example.
I mostly mentioned Bot Management because of the more granular approach, mostly for passers by. I think each use case can be a little unique but having the ability to exclude known bots and the ability to use Challenges to separate the traffic, is a great option to have.
Most definitely. But I guess we went way too much into detail at this point.
@disruptive, yes, as mentioned you can either import the data via the API or create one (or two) firewall rule which contains all the values. Would I recommend to go that way? No
I usually get thousands of hits to my site’s registration/login pages from cloud providers and definitely know my site isn’t that popular enough that cloud provider ASNs would hit my login page at 100+ requests/second