Softblocking 35.0.0.0/8

[IJustWanttoPost]

Hi,

What are your thoughts on softblocking the entire 35.0.0.0/8 ip range?

There seems to be many Comcast, Boost Mobile and other "Residential IPS" sold through this route... but they all appear to be cloud.

After researching, it appears these might be leased IP ranges on the cloud network.

Do you have traffic from this ip range that is legitimate?

Will softblocking 35.0.0.0/8 and basically classifying it as 'bot' traffic on my website harm anything?

What are your thoughts? What should I know before doing something like this?

Thank you for reading!

[not2easy]

First, what is softblocking? As far as I know there is block and not block. What is the method of softblocking, is this using captcha?

Most of 35.0.0.0/8 is either Amazon server or Google-Cloud ranges and many mobile services do use cloud servers. If you block the entire range you'll be blocking bots, scrapers and human visitors.

It is best to know for sure what kind of UAs and behavior you do not want before locking the door on actual visitors.

[IJustWanttoPost]

"First, what is softblocking?"

Sorry! I should have explained that better (it can mean anything basically). For me softblocking means that I have stricter resources limits and monitor things like user signups, access to new posts and more. It doesn't mean they are going to get a captcha or a less user experience nescessarly.

"Most of 35.0.0.0/8 is either Amazon server or Google-Cloud ranges and many mobile services do use cloud servers. If you block the entire range you'll be blocking bots, scrapers and human visitors."

The softblocking should explain better. What i'm trying to do is prevent automated scrapers (I had 400,000 attempts in the last 30 days!).

The UA's that I see... look legitimate. They appear to be real users... except their profile matches thousands of other requests from cloud ips... It's like they found this hole and are using it to get through and why i'm asking all these questions basically....

When I ask the AI, do any research, it says that Allocation is different than Brand Labeling...

35.0.0.0/8 is allocated to the cloud therefore it goes through the Cloud infrastructure.. They cannot sell ips to other companies... so it's confusing

[IJustWanttoPost]

Like, look at this IP (it claims to be Boost Mobile): [whois.arin.net...]

I hope it's OK to post ARIN.net link (they should be the IP source) of all the Whois websites...

[not2easy]

You're right, that is not the same as blocking.

As for the AI explanation it looks more confusing than just what it shows in the Boost Mobile screenshot, but that image explains that it is owned by Amazon Web Services and currently used by Boost Mobile. The range is Amazon's, leased to Boost Mobile. That does not guarantee that the visitor is a human, but that they do have a Boost Mobile SIM card. I'd take a look at your logs to see if the browser and activity are human.

(edited to add) Currently, the last post (# 5128060) by jmccormac in the monthly December 2025 Google Search Observations thread [webmasterworld.com...] discusses that issue.

[IJustWanttoPost]

"As for the AI explanation it looks more confusing than just what it shows in the Boost Mobile screenshot, but that image explains that it is owned by Amazon Web Services and currently used by Boost Mobile"

Yes, I know it's really confusing.. but I think it's making sense...

Isn't it more like... it's an Amazon Cloud Server... and Amazon has announced that the customer of that cloud server is Boost Mobile?

What are Amazon's Terms? Do they "update" in a timelely manner? (WHO KNOWS?)

So it could be a Boost Mobile Amazon Cloud server, but it shouldn't be a Boost Mobile customer using a mobile phone.

Right? If anybody else has more info, please post!

[not2easy]

Amazon's server controls all IPs from

Net Range35.39.96.0 - 35.39.127.255
CIDR35.39.96.0/19

and Boost Mobile is the client of that range since 2024-11-04 until further notice.

Your visitor may be a Boost Customer. Or not.

[IJustWanttoPost]

"and Boost Mobile is the client of that range since 2024-11-04 until further notice.

Your visitor may be a Boost Customer. Or not."

That is true! They WERE a customer on 2024/11/04, are they still today? They announce when customers buy ips, but when they leave, they don't tell anybody...

Do they? Here's what I see ----------------------

If a company stops using AWS the process looks like this.
AWS withdraws the BGP route or reassigns it internally often immediately.
The IP may be reused by AWS for another customer without any public notice.

There is no public announcement when a customer leaves AWS.
No flag no broadcast and no ownership change notice unless the IP block itself is transferred which is rare.

This is why IP intelligence databases often look wrong or outdated.
They guess based on history routing patterns and reverse DNS not authoritative ownership.

[IJustWanttoPost]

I'll post the BGP info here... (AI)

What is BGP?
Think of it like this.
Allocation is owning the land.
BGP is putting the address on the highway signs.
Server assignment is deciding which apartment inside the building gets the mail.

A single BGP route can cover millions of IPs even though only a small portion are actively assigned to servers.
Those unused IPs still appear routed because the block is reachable as a whole.


-------------
I'm just basically trying to figure out if these are VPN / Cloud users or leigitimate users.

[IJustWanttoPost]

Sorry , 1 more addition-

The reason I say the whole 35.x.x.x is because there are multiple Boost Mobile ranges within it likely around five to ten /19 blocks.

There are also several Comcast blocks in the 35.x.x.x range that appear to exhibit the same disruptive behavior.

The others are legitimate cloud services.

[tangor]

What do the headers look like?

[IJustWanttoPost]

"What do the headers look like?"

They are completely normal...


Here is an example of what these IPS will do in the future (soon, as people notice there's something strange with these ips)..

Whois this ip: 100.49.13.0/24

On most Whois platforms is will say that it's an Amazon IP owned by Spring Communications...

The ARIN database has been updated and only shows that it's ownedby Amaon as of right now:

Net Range100.48.0.0 - 100.63.255.255
CIDR100.48.0.0/12
NameAMAZON-IAD
HandleNET-100-48-0-0-2
ParentAMAZO-4 (NET-100-48-0-0-1)
Net TypeReallocated
OrganizationAmazon Data Services Northern Virginia (ADSN-1)
Registration Date2025-08-19
Last Updated2025-08-19

So it's like whack a mole... ARIN delays by up to 2 months,.. Amazon by a few months.. and we just have wackamole...

[IJustWanttoPost]

So I think you next question will be "how do I know then it's bad traffic?"

Because they are using anti fingerprint techniques that actually make them stand out 1000%

[lucy24]

"What do the headers look like?"

They are completely normal...

This is not quite as informative as you may think. Headers are continuously evolving; last year’s fishy-looking aberration may be next year’s Proof Of Humanity.

[IJustWanttoPost]

"This is not quite as informative as you may think. Headers are continuously evolving; last year’s fishy-looking aberration may be next year’s Proof Of Humanity."

They are using real devices.... I think it's a proxy provider that sells data and offers "website unblocker services".

They are using a pool of thousands of devices...

It appears to be devices that users are downloading some program and being paid something like .$50 cents a gigabyte and are unknowingly being used in things like a DDOS and more.

[IJustWanttoPost]

"This is not quite as informative as you may think. Headers are continuously evolving; last year’s fishy-looking aberration may be next year’s Proof Of Humanity."

When you say this, it doesn't register with me.... I mean it does but I don't 100% know what your referring to...

What am I looking for in the headers that would be fishy looking?

Do you mean things like the order of headers and the version of the browser? AKA, I need a huge dataset of informatoin to be able to determine that..

AKA

Chrome 140 = Order wrong = Bot

That type of thing?

[IJustWanttoPost]

Sorry, to add one more thing: isn't the header inconsistancies the things that Cloudflare does?

Like doens't Cloudflare have thousands of rules to determine those inconsistancies? Like missing Sec-Fetch-Dest, header ordering, suspiscious accept values, etc.

I use Cloudflare..

Are there some header anomolies that you suggest to pay closer attention to? I don't have access to TLS Fingerprinting as it's thousands of dollars a month.

[lucy24]

I only meant that “completely normal” is so vague as to be meaningless. You could say “there are no glaring header anomalies” but that isn’t saying much.

[IJustWanttoPost]

Ya I See.. this area has so many words like that it makes it difficult for sure...

By the time we read what we're actualy talking about, we have a book written already :0x

Anyway, one more thing that I can really note about this situation is that inside of Cloudflare, these ips are reported as:

Source ASNs
398378 - BOOST-MOBILE

Here's to finding out more info on these to validate if they are real or not and/or finding more like them

[SumGuy]

You haven't posted an actual IP (that I can see anyways). Just a CIDR. So I can't check your examples. So why don't you try these resources:

Abused IP database (www . abuseipdb . com/check/I.P.address.here)
Spur (spur . us/context/I.P.address.here)

If you're seeing a lot of forum-spam type of abuse, it will likely show up more with abusedIPdb than spur.

You can either block a single /24 CIDR if you're only being hit massively by a single IP or IP's in a single /24, or if it's a lot wider then that then block the entire 398378 (it's only 45k IP's I'm sure can be condensed into about 12 CIDR's).

[jmccormac]

Some of Google's AI explanations on neworking/DNS are crap driven by Natural Stupidity. (My opinion on Google's domain name expertise is even more cynical and involves their inability to use a map and a flashlight.) I was checking for details on an ISP (UCC) in Kuwait and Google's AI garbage claimed It referred to UCC (University College Cork) eventhough the query had the 'Kuwait' keyword. It is extremely dangerous to rely on Google's AI for this kind of research.

At an IP level, the Internet is extremely complex because IP ranges are bought, sold and reassigned. WHOIS data can be decades out of date. Any IP intelligence operation is going to be playing catch-up. As for the "service" that Netflix uses for Ireland, it is not competent. (Have two broadband connections and it thinks that they are over a hundred miles apart even though both are assigned to the same location.) That example, and the Amazon/Boost example above illustrate the deficiencies in many IP "intelligence" operations. They can hit the largest range from an IP registry and stop checking. Thus the Amazon range above might appear to be just Amazon until some digging is done to find out the owner of a range. With ARIN, large ranges can have multiple "#start" sections in a WHOIS query for an IP. I've seen a few where it goes from the range owner to subnet and then to another smaller subnet.The smaller subnets might not be in the same country as the range owner.

There is an increasing trend of scrapers (specifically) using mobile Internet SIMs (typically pay-as-you-go SIMs) to avoid data centre blocks on scrapers. These mobile Internet scrapers execute Javascript and try to be human-like. They typically use services in countries where access is relatively cheap. If you see an uptick in activity from a mobile ISP that is completely out of profile (and perhaps out of country) for your site, that sudden interest is likely to be scrapers.

With large operators like Amazon, IP ranges are often not put into use immediately. It has a very complex structure and has multiple country level operations where it assigns addresses. Amazon's (and MSFT's) geofeed can be very useful in this respect.

Many of the larger players have ranges in various countries. Operators like Comcast can be extremely complex in how they delegate ranges. They have regional/local ranges but they often have small business and end-user customers beneath those ranges.

As a rule of thumb when dealing with a mobile ISP, if it has a pay-as-you-go scheme for SIMs, that increases the risk factor for scraping. The answer to that question cannot be found in WHOIS databases. There is also an increasing use of IP brokers like IPXO, Some of these ranges are assigned to "private customers". Some are legitimate users and it would need a correlation with logs. Many of them have no reverse delegation. To quote the character Sam from the movie 'Ronin', "Whenever there is any doubt, there is no doubt."

Regards...jmcc

[SumGuy]

For what it's worth, regarding 35.0.0.0/8, for me it's one of the /8's that has a relatively high signal to noise ratio. But not a lot of traffic.

Since April 2021 I've seen 1574 page requests from 37 unique IP's. This traffic comes from various.spectrum.com (AS20115, AS33363, AS20115 - which are Charter, BHN, TWC) and MERIT (AS237 - U of Michigan system or more broadly various MI-based EDU's).

I see a handful of AWS hits, no doubt I've since blocked the /16's they've come from.

I have only 28 CIDR entries in my IP blocking list for 35/8. I'm blocking 35.71 to 35.95 and 35.153 to 35.248. I'm guessing they belong to AWS or Google-User, and they're getting blocked likely for port scanning or spam (email) attempted or actual delivery.

So I am blocking about half of 35.0.0.0/8 which probably maps to AWS and Goog and for reasons other then http abuse, although because I'm not logging it I have no visibility into how much web abuse might be coming from AWS and Goog. Mind you - this is just HTTPS (port 443) traffic that I'm looking at here. There might be more http (port 80) noise coming from 35/8 that I haven't done any analysis of.

The OP had a problem with abuse from AS398378 (Boost Mobile) and I see no traffic from their various 50K IP's (not just their IP's in 35/8) and I'm not IP-blocking that ASN.

If desired, all of Boost Mobile's 35.0.0.0/8 IP's can be IP-blocked using only these 2 CIDR entries:

35.33.128.0/17
35.39.96.0/19