https://bgp.he.net/AS3257#_prefixes

uab code200, egihosting, web2objects...
I banned this bot farm entirely 5 years ago.

This thread would be more useful if it included numeric IP ranges.

Yea, lots of code200, also web2objects, and Ace Data Centers (and a lot more). There's 8.6 million IP's, I'm probably also blocking the whole thing.

> This thread would be more useful if it included numeric IP ranges.

Do you want a condensed IPv4 list of AS3257?

sacjet.com,web2objects.com,egihosting.com,cloudtechlabs.com,zare.com,Ace Data Centers,code200,netutils.io,binbox,my-tec-sa.com - these all are under GTT(AS3257) with sacjet,web2objects,egihosting being most prominent at this point.

A slow scrape started on 6/15/2025 and is currently swinging.

>>> This thread would be more useful if it included numeric IP ranges.

These are all under GTT Communications Inc.

138.226.96.0/20 - sacjet
167.160.56.0/21 - web2objects
142.147.192.0/19 - web2objects
45.41.132.0/22 - web2objects
23.230.234.0/23 - GTT
142.252.60.0/22 - egihosting
104.238.32.0/24 - web2objects
138.226.20.187 - sacjet
142.147.192.0/19 - web2objects
45.61.115.0/24 - web2objects
45.41.132.0/22 - web2objects
..... there are tone of these

List of IPs from GTT that made thru software firewall since Jan (i was gonna type 6) :

138.226.30.191
138.226.107.108
138.226.20.25
45.41.175.200
167.160.63.11
45.41.145.120
45.41.165.23
138.226.18.214
142.147.216.227
138.226.99.28
138.226.108.175
167.160.63.35
64.57.130.169
45.61.115.187
138.226.24.232
167.160.62.80
167.160.57.76
142.147.203.42
104.194.200.245
138.226.104.187
167.160.59.24
142.147.201.2
45.41.133.220
138.226.104.63
167.160.59.92
23.230.234.53
142.252.60.140
138.226.96.232
104.238.32.50
138.226.20.187
142.147.197.249
45.61.115.107
45.41.132.92
45.61.67.152
45.41.146.117
45.41.147.41
138.226.109.85
142.252.60.238
167.160.57.218
45.41.136.28
45.41.181.211
138.226.96.95
23.230.186.112
45.61.115.147
45.41.164.184
45.41.165.26
167.160.55.2
45.41.167.221
45.41.175.164
142.147.221.154
45.41.135.155

added: these are normal headers requests, straight shooters for an URI, no other files requested. They do share Server Session data/id in some instances, but mostly one ofs.

If you were blocking via CIDR there are only 10 lines:

23.230.186.112 = 23.230.0.0 - 23.230.255.255 = 23.230.0.0/16 EGI
23.230.234.53

45.41.132.92 = 45.41.128.0 - 45.41.191.255 = 45.41.128.0/18 (VPN)
45.41.133.220
45.41.135.155
45.41.136.28
45.41.145.120
45.41.146.117
45.41.147.41
45.41.164.184
45.41.165.23
45.41.165.26
45.41.167.221
45.41.175.164
45.41.175.200
45.41.181.211

45.61.67.152 = 45.61.64.0 - 45.61.127.255 = 45.61.64.0/18 (WEB2OBJECTS-07)
45.61.115.107
45.61.115.147
45.61.115.187

64.57.130.169 = 64.57.128.0 - 64.57.143.255 = 64.57.128.0/20 (WEB2OBJECTS-03)

104.194.200.245 = 104.194.192.0 - 104.194.223.255 = 104.194.192.0/19 (Web2Objects LLC (WL-113)

104.238.32.50 = 104.238.32.0 - 104.238.63.255 = 104.238.32.0/19 (Web2Objects LLC (WL-113)

138.226.18.214 = 138.226.0.0 - 138.226.255.255 = 138.226.0.0/16 (US-AVIATION-19930901)
138.226.20.25
138.226.20.187
138.226.24.232
138.226.30.191
138.226.96.95
138.226.96.232
138.226.99.28
138.226.104.63
138.226.104.187
138.226.107.108
138.226.108.175
138.226.109.85

142.147.197.249 = 142.147.128.0 - 142.147.255.255 = 142.147.128.0/17 (WEB2OBJECTS-08)
142.147.201.2
142.147.203.42
142.147.216.227
142.147.221.154

142.252.60.140 = 142.252.0.0 - 142.252.255.255 = 142.252.0.0/16 = (EGNL-1/EGI)
142.252.60.238

167.160.55.2 = 167.160.32.0 - 167.160.63.255 = 167.160.32.0/19 (WEB2OBJECTS-04)
167.160.57.76
167.160.57.218
167.160.59.24
167.160.59.92
167.160.62.80
167.160.63.11
167.160.63.35

UPDATE:
...and Just Like That.. for now for some reason all traffic affiliated with AS3257 stopped. Not a pip...

14923 requests blocked since 2025/06/15, 1700+- got thru.

With most requests made to root, 2000+- never followed 301 from none -www or none https URIs redirects.

Lots of requests were made with a root as a referrer to inner pages that were never linked from the root, that was a big help. Lots of requests were made to URIs that are long been rewritten and had no external kinks pointing to them either.

I have a strong filling that URI Set being probed was scraped from BING SERP and is at least 2 years old.

Guard rails are now in place. Home brewed Captcha, JS Detection, headers API Calls.

What made this type of scrape diff is same IP almost never requested more 2 URIs per session, so as soon as they get 403 they moved to DIFF IP.

Another trick learned here(i am talking geek here) is that these requests came in bursts, so keeping track on Application level which URL was requested and blocked in server memory and comparing it to the subsequent requests seemed to help.

They didn't just go after this domain, so keeping track(automagicaly, blocked IPs are kept in CENTRAL DB) with other sites I run helped as well

Also Keeping a local DB with entries that map IPs to AS3257, ABUSEIPDB API calls to get to Domain IP Register to(not ASN) helped a lot as well.

... and look at this, I am Almost an AI Agent now..... ;)

Lots of requests were made with a root as a referrer to inner pages that were never linked from the root, that was a big help. Lots of requests were made to URIs that are long been rewritten and had no external kinks pointing to them either.

Another good one is extensionless URLs if your site doesn't use them: either a request for extensionless giving anything as referer, or a request for an otherwise-valid URL giving extensionless as referer. Nice try, robot.

-- Another good one is extensionless URLs

Great Tip!

It is a loaded BIG IF though. In my experience Bots that try to access extensionless URLs do not follow 301s.

I have a DB Table with all valid only URIs on each site we manage, with another DB table with allowed CGI.Query_String variations allowed per URI in the first table. Each URI has an ID, each QS has an ID, there is a max length for query strings, there is a proper order of query strings enforced. There is a proper CASE of URIs and Query Strings(all though allowed are only in lower case).

Rule 1 = URI(with query_string) comes in:
1.DB Look UP >> No match first time gets recorded >> 301 to a Proper URI .
2. Subsequent Requests >> all 404s.
3. Later based on a review it is either 404d or Drop Requests forever.

With the exception of if we rename the URI in the Table 1 for a proper Old URI. Then the Table 1 is updated to automagicaly 301 to a new URI. Custom CSM has an auto-generated .htaccess rewrite-map file to ColdCusion template with the ID of URI, then redirect is logged into DB and redirected from the sites code to a ProperURI...

All pages on the site have a proper : <link rel="canonical" href="https://www.example.tld/thisProperURI"> tag and a <base href="https://www.example.tld/">, no exceptions.

But, someone links to your page from exampleA.tld/reffered.html with a link to your directory page exampleB.tld/directory omitting '/' at the end is a 2 scenario thingy:

Allowed Search Spider = Drop Request(I did not linked to it on my site, go crash some egg shells instead).
Everybody else: see Rule 1 above.
-----------------------------------------------

Here is one of the old ones for IIS hosted Sites:

Double // in URI

exampleC.tld/directory//page.whatever

Here is one of the old ones for IIS hosted Sites:

Double // in URI

Many years ago, I accidentally created some internal links with // mid-URL (had to do with a cluster of now-defunct php-generated pages). From this I learned that Apache simply ignores any duplicate // in the URL. In order to redirect to the single-/ version, I had to use a RewriteCond; double // in a RewriteRule pattern isn’t recognized.

For some reason, G### persists in asking for one specific subdirectory with // from their old http shopping list; there's also one specific page that they persist in requesting without final /. * I'm tempted to simply block both patterns unconditionally; then maybe they'll stop asking.

* Got a vague notion that when I first submitted this page to {respectable curated directory whose rss feed is also read by robots} I forgot the final / and had to change it. But that was in October 2018, so come on, G.

RE:
# Redirect to remove double slash within URL-path
RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
RewriteRule . http://www.example.com%1/%2 [R=301,L]
#
# Redirect to remove multiple slashes before URL-path
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ //+([^\ ]*)
RewriteRule .* http://www.example.com/%1 [R=301,L]

Not Sure, but This^^ was working last time i checked on IsapiRewrite for IIS

Ooh, mine's entirely different. (Since only one directory is involved, and the // is always in the same place it's a bit simpler, but multi-directories wouldn't be much more complicated.)

:: insert boilerplate about non-final .* or .+ in any RegEx ::

RewriteCond %{REQUEST_URI} /paintings//+(.*)
RewriteRule ^paintings https://example.com/paintings/%1 [R=301,L]