Further securing bitcartcc installs

[Jayd603]

I was hoping all requests would forward directly from my billing system to bitcartcc through curl etc, that would be easy, just restrict the bitcart nginx to allow my billing system. but it seems to use assets from all areas including /api and /admin (otherwise i could restrict one or both of these) .. I notice it's mostly .js files so I could try allowing access on *.js and a per file basis as needed but thought i'd get others thoughts on this. I'm trying to allow only the bare minimum to be accessible publicly to minimize exposure.

[MrNaif2018]

Hi! Do you mean the CDN files? How exactly would you want to limit them? We can probably host those locally instead of using CDNs (though CDNs are usually better with loading speed)

[MrNaif2018]

About disabling main store url from crawlers: we actually have a setting in admin panel which should prevent robots from scraping it by setting (though only search engine crawlers probably respect that). I think we should respect this setting in the store page too, right?

[Jayd603]

I'd rather have it throw a 404 not found from nginx. Much less interesting to network scanners. This is for my config only, not saying it should be merged into bitcart

[MrNaif2018]

As for custom nginx config, I think you can create a custom component in generator/docker-components directory which would modify needed services (but it might not fully work, as we only provide a way to append nginx config, not override):

let's say it's named nginx-overrides.yml

store:
      ADDITIONAL_NGINX_CONFIG: "config string here"

then do

export BITCART_ADDITIONAL_COMPONENTS=$BITCART_ADDITIONAL_COMPONENTS,nginx-overrides
export BITCART_DOCKER_IMAGE=bitcartcc/docker-compose-generator:local # note: this setting is actually not saved as other settings are
./setup.sh

But yeah, returning 404 probably won't be in main bitcart (:

By the way, if you want to return 404, how would you handle regular users? Or do you want to disable it at all?
If so there's a much easier way:

export BITCART_INSTALL=backend
export BITCART_ADDITIONAL_COMPONENTS=admin
./setup.sh

P.S. I will add ability to exclude components in a few minutes

[Jayd603]

Right, as of now I am only using WHMCS so don't need the default cart right now. I think I modified the template that generates the nginx config, overrides would be nice if they aren't already there but it's not much work for me to modify so no big deal.

I see, so I could install with backend and admin instead, good to know. I actually like the idea of having a regular cart there in case I want to accept payments outside of WHMCS at a later time, I could just change the nginx config back.

[MrNaif2018]

Exclude components has now landed, so that you can do only:

export BITCART_EXCLUDE_COMPONENTS=store
./setup.sh

[Jayd603]

It seems like my attempts to use 'return 404;' in the nginx config worked except in WHMCS, invoices don't refresh to show as PAID any more. They are marked as paid in whmcs but no browser refresh happens on payment which could confuse the customer. Strange.

I'd still like to lock down the main cart home page or return a blank/404. Exclude components makes the admin page the new root service for the domain in nginx. That would be fine but how can we add IP access control to the admin interface? Do some of the admin bits need to be reached by the clients browser/WHMCS when processing transactions? I think last time I checked they did. If that's the case IP access control may need to be implemented within bitcartcc right?

[Jayd603]

So I did a refresh of everything and enabled XMR. Great! I used BITCART_EXCLUDE_COMPONENTS=store and it worked, now only a login page is displayed. The problem is the WHMCS plugin fails to function now. Possibly it's using things from the store. Shouldn't it be API-only? I'll need to look at that code.

I think for now, a way to blank out or install a redirect somewhere else on the index page for the domain/URL will be an improvement for hiding from crawlers/scanners. In the future we want the WHMCS plugin to only require the API. Right now, if I restrict the bitcart server to only be accessible from the WHMCS server , it also breaks the WHMCS plugin, the WHMCS users client machine is connecting directly to the bitcart server store for some stuff apparently but I'd need to look closer.

Oh... another thing I noticed - connecting to the bitcart machine with a raw IP will still display everything with an SSL error, same for if other hostnames are used. so if another entirely unrelated hostname points to the server, everything will still work with an SSL error. it should just not work - ie, display a 404 error or something like that. some nginx config changes should fix it.

[Jayd603]

Also, a way to add in a robots.txt file or manipulate it through the GUI would be nice. I mean I can just add one in myself no problem but for other people tjhat don't work with docker and linux much...

[Jayd603]

Here are my changes to nginx.tmpl - not saying this is ok for a commit or anything - just showing you what i changed to drop a connection that isn't using the actual hostname of the store.

--- ./nginx.tmpl.orig	2023-11-16 10:49:21.789820608 -0500
+++ nginx.tmpl	2023-11-16 10:48:31.818637834 -0500
@@ -134,12 +134,12 @@
 {{ if (and (exists "/etc/nginx/certs/default.crt") (exists "/etc/nginx/certs/default.key")) }}
 server {
 	server_name _; # This is just an invalid value which will never trigger on a real hostname.
-	listen 443 ssl http2;
+	listen 443 ssl http2 default_server;
 	{{ if $enable_ipv6 }}
 	listen [::]:443 ssl http2;
 	{{ end }}
 	access_log /var/log/nginx/access.log vhost;
-	return 503;
+	return 444;
 
 	ssl_session_tickets off;
 	ssl_certificate /etc/nginx/certs/default.crt;
@@ -249,6 +249,7 @@
 	{{ if $enable_ipv6 }}
 	listen [::]:80;
 	{{ end }}
+	return 444;
 	access_log /var/log/nginx/access.log vhost;
 	location / {
 		proxy_pass {{ trim $proto }}://{{ trim $upstream_name }};
@@ -273,9 +274,9 @@
 server {
     client_max_body_size 100M;
 	server_name {{ $host }};
-	listen 443 ssl http2 {{ $default_server }};
+	listen 443 ssl http2;
 	{{ if $enable_ipv6 }}
-	listen [::]:443 ssl http2 {{ $default_server }};
+	listen [::]:443 ssl http2;
 	{{ end }}
 	access_log /var/log/nginx/access.log vhost;

[g00g1]

ssl_reject_handshake might be a better way to reset connection.