cprapid hostnames in Apache vhosts
I've seen some older threads regarding the generated cprapid hostnames, but on one of my hosts, Wednesday morning - when Rocky Linux was updated from 9.4 to 9.5 , suddenly *all* my vhost configurations got the fqdn.ip.cprapid.com hostnames, although they *do* resolve (not to the server IP though, as I'm behind Cloudflare).
*How* can I get rid of these hosts ??? Unparked all *.cprapid.com hosts , still after running /scripts/rebuildhttpdconf , these hosts get added again.
I even restored one site from a backup (w/o the *.cprapid.com hosts) and the fqdn.ip.cprapid.com were added *again* .
From https://support.cpanel.net/hc/en-us/articles/360052682654-Can-I-disable-the-automatically-issued-hostnames-during-cPanel-installation:
"The cprapid.com hostnames are only issued if the hostname does not resolve, and is done so that a free signed SSL can be issued for the hostname. The internal tracking case for this issue is CPANEL-33851"
- but all hostnames *do* resolve ?!
There surely must be a way to disable this behavior ?
-
This is on 124.0.10 RELEASE
0 -
Hey there! Do the hostnames resolve from that particular server? Is it possible that system is experiencing a DNS issue of some sort, causing the hostnames not to resolve properly?
If that isn't what is happening, it would likely be best to create a ticket to determine why the cprapid entries are being added, as there isn't a way to stop those from being automatically added.
0 -
cPRex - yes, *all* hostnames resolve - although the server is not authoritative for all the domains and I'm using external resolvers in /etc/resolv.conf anyways.
There *was* an issue with the local bind server during the automatic update from Rocky 9.4 to 9.5 this week, there were duplicates in named.conf and one orphan (no zone file).
Cleaned up named.conf and bind is running again.
The current state is that I still have the *.cprapid.com sosts as server aliases in httpd.conf - however, if I delete the SSL cert, the *.cprapid.com hosts are not added as SAN to the cert - which is good, however, I would like to get rid of all the *.cprapid.com server aliases now !
As I've purchased cPanel through a reseller, I can't open a ticket at cPanel directly...0 -
Just found this https://support.cpanel.net/hc/en-us/articles/27772003203607-cprapid-com-Subdomains-Added-to-ServerAlias - however,
whmapi1 --output=jsonpretty get_domain_info
does not return *any* *.cprapid.com hostname ?!0 -
On top of that, suddenly I have to mitigate thousand of bots accessing those *.cprapid.com hosts - great. I have no idea where they come from, but as long as they resolve, they will continue coming.
This *.cprapid.com thing reminds me of the days when Verisign wanted to introduce a wildcard for the .com zone. This is a major headache tbh.
x.x.x.x - - [24/Nov/2024:10:59:29 +0100] "GET /.env.development HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:30 +0100] "GET /.gitlab-ci.yml HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:31 +0100] "GET /.env.gitlab HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:31 +0100] "GET /config.yml HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:32 +0100] "GET /bitbucket-pipelines.yml HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:32 +0100] "GET /.env.bitbucket HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:33 +0100] "GET /application.properties HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:33 +0100] "GET /config.js HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:34 +0100] "GET /config.json HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:34 +0100] "GET /.npmrc HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:35 +0100] "GET /wp-config.php HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:36 +0100] "GET /config/database.yml HTTP/1.1" 444 0 "-" "-" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:10:59:46 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:11:00:16 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:11:00:20 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:11:02:23 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:11:02:24 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:11:02:58 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [24/Nov/2024:11:06:06 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36" "-" "x.x.y-y-y-y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-1 -
There was another thread about this recently where I pointed a user to the following issue report we have created with our developers:
Unfortunately the only workaround at this time is to remove those domains manually from the server is they are causing issues. I believe the current plan from the development team is to make these optional, as these are intended for users to access their site before the DNS is configured, so you should have the option to disable them.
0 -
In my case, the damage has already been done and the only way to undo it would be by *not* resolving *.cprapid.com hosts anymore.
In addition to malicious bots, now all those "statistic" bots come crawling as well:
x.x.x.x - - [03/Dec/2024:00:46:49 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)" "-" "y.y.y.y.cprapid.com" sn="y.y.y.y" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [03/Dec/2024:10:31:29 +0100] "GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (compatible; InternetMeasurement/1.0; +https://internet-measurement.com/)" "-" "y.y.y.y.cprapid.com" sn="localhost" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-
x.x.x.x - - [03/Dec/2024:10:51:14 +0100] "GET / HTTP/1.1" 444 0 "-" "Expanse, a Palo Alto Networks company, searches across the global IPv4 space multiple times per day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: scaninfo@paloaltonetworks.com" "-" "y.y.y.y.cprapid.com" sn="y.y.y.y" rt=0.000 ua="-" us="-" ut="-" ul="-" cs=-I will never get rid of these bots as long as the *.cprapid.com hosts resolve to my IPs in DNS !!!
And all of this only because on November 20th, for about one day, all those hosts had a *.cprapid.com as a SAN in the TLS certificate until I unparked them. *And* the cprapid.com hosts are still in httpd.conf.
0 -
henker - I'm sorry to hear that! I wouldn't expect DNS entries to still be resolving today, December 3rd, if you have removed those entries from DNS. If that is somehow cached somewhere, can you block the bots?
0 -
Of course they still resolve - as *everything* does for *.cprapid.com ! It's not that I am running the authoritative nameservers for cprapid.com...
Trydig www.google.com.142-250-110-104.cprapid.com
dig www.cpanel.com.104-21-42-250.cprapid.com
And yes, I can currently mitigate anything accessing *.cprapid.com with a 444.
1 -
Thanks for the details - yes, everything for cprapid will resolve to something as that is in place so there is no requirement to manually update those records. Anytime we create a *.cprapid domain it just instantly works. I was just stuck on "hostname" referring to the hostname of the server for a while, and not just "hosts" in general, so I was headed down the wrong path.
I honestly don't have a recommendation about the bot traffic, as this wouldn't be handled any differently than any other "attack" on the system, whether it's a cprapid domain or one of your other domains. It just so happens that is what the bots latched onto for your system.
I'm sorry I don't have a better option here but we don't have a way to keep those cprapid domains from resolving.
If you'd like to submit a ticket so the server could be examined we'd be happy to take a look directly on the machine.
0 -
I honestly don't have a recommendation about the bot traffic, as this wouldn't be handled any differently than any other "attack" on the system, whether it's a cprapid domain or one of your other domains.
Being the only difference that "dumb" hosts usually end up in the default host where they can be dealt with for simple GET / requests, but now all of a sudden with a *.cprapid.com host, they end up in a "real" virtual server and crawl all the links they find.
I'm sorry I don't have a better option here but we don't have a way to keep those cprapid domains from resolving.
If cPanel can't make this feature an opt-in choice, then there should be a possibility to opt-out.
If you'd like to submit a ticket so the server could be examined we'd be happy to take a look directly on the machine.
As I've purchased cPanel through a reseller, I can't submit a ticket directly.
Just one question for my understanding - from https://support.cpanel.net/hc/en-us/articles/27772003203607-cprapid-com-Subdomains-Added-to-ServerAlias :
In cPanel version 124, domains such as
cptesting.tld.10-2-50-186.cprapid.com, wherecptesting.tldis a main or parked domain on a cPanel account, are added to theServerAliassection of the Apachehttpd.conffile.So this is a default setting now since version 124 ? There is no way to get rid of the *.cprapid.com ServerAliases even if these domains are *not* parked ? This would be insane !
1 -
This is a default setting in version 124 now, correct. However, we do have case CPANEL-46086 open to make this an option setting that can be toggled by the server admin at the root level, but it's not yet available.
I've also started a larger discussion about making tools optional or removable whenever we add features, such as the discussion that was happening in https://support.cpanel.net/hc/en-us/community/posts/27451066075927 about a tool to remove 360 Monitoring completely.
If I hear any updates on that I'll be sure to post them here!
0
Please sign in to leave a comment.
Comments
12 comments