NodeBB socket with CloudFlare

DownPW

Following this topic, I understood that CloudFlare in its Free Plan is not my friend but I wonder.

one of CloudFlare’s features of hiding the origin server’s IP is THE feature that makes me not really want to leave CloudFlare unless there’s another way to do it ?

That said, the problem being mainly the socket connections, wouldn’t it be possible to pass ONLY its connections without going through CloudFlare?

To do this, you will have to create a subdomain of the root domain and not proxy it via Cloudflare but just in DNS Only, then indicate this in nodebb’s config.json

If I’m not mistaken, this might fix the wss and error 400 issues.

I saw this topic on which you intervened with your position, but is this method still viable, is it functional?

At the end of this thread it reads:

@phenomlab if there are those who are using cloudflare, we do have it in our roadmap to eventually deprecate socket.io and use socket sent events instead.
This would solve a lot of problem with CloudFlare’s free plan no?

This would solve a lot of problem with CloudFlare’s free plan no?

Afterwards I am ready to leave CloudFlare if another possibility of hiding your IP is possible but in the meantime, could this be a solution ?

Thanks

phenomlab

@DownPW said in NodeBB socket with CloudFlare:

one of CloudFlare’s features of hiding the origin server’s IP is THE feature that makes me not really want to leave CloudFlare unless there’s another way to do it ?

No, there isn’t. The way Cloudflare works is to force all of the traffic through a reverse proxy which they control - so even if your request originates in France, it’s going to the US first to be spooled through Cloudflare’s proxy service before being sent onto the origin server.

This has two undesired results

Traffic eavesdropping by Cloudflare
Sending traffic through a US entity meaning privacy is not going to be respected, or even if it is, it will me much less than you desire and you cannot change that

Legacy tools such as cloudfail.py could easily bypass the reverse proxy and expose the origin address. These days, that tool only works on seriously weak configurations, but ZenRows will still work and can easily expose the IP you are attempting to hide.

https://www.zenrows.com/blog/cloudfail

You could set up a VPS with a reverse proxy to send the requests onto the origin, so you would only be exposing the reverse proxy itself in the same manner as Cloudflare, but that adds an additional hop, and also presents a single point of failure and something else to monitor and check.

@DownPW said in NodeBB socket with CloudFlare:

That said, the problem being mainly the socket connections, wouldn’t it be possible to pass ONLY its connections without going through CloudFlare? To do this, you will have to create a subdomain of the root domain and not proxy it via Cloudflare but just in DNS Only, then indicate this in nodebb’s config.json

That’s possible, but you would then need to route socket.io through a sub domain in DNS mode only. This is pointless in terms of protection, as the sub domain could then be used to expose the origin host, and you’ve gained nothing.

@DownPW said in NodeBB socket with CloudFlare:

If I’m not mistaken, this might fix the wss and error 400 issues.

Correct, but the above point still remains

@DownPW said in NodeBB socket with CloudFlare:

This would solve a lot of problem with CloudFlare’s free plan no?

Not really. You still have the Bot Fight Mode issue where the enhanced protection means your site cannot be crawled by Google for example, as their entire ASN will be blocked.

@DownPW said in NodeBB socket with CloudFlare:

Afterwards I am ready to leave CloudFlare if another possibility of hiding your IP is possible but in the meantime, could this be a solution ?

I don’t understand why people insist on hiding behind Cloudflare.

Going through the proxy service at Cloudflare will slow your traffic down. Think of a funnel - it’s wide at the top, and very narrow at the bottom to fit into the available space (such as the neck of a bottle). Traffic arriving here starts out with having say 8 lanes to enter, then goes down to 1 with severe congestion meaning everything else has to wait behind what’s in front.

Effectively, something like this

traffic jam-min.jpg

The free plan is first come, first served meaning there is no guarantees of traffic being delivered, meaning that anything time sensitive will suffer as a result. This is that causes socket.io to respond with http 400 because the connection is not established in time.

If you think about how TCP works, then in a lot of cases, the delay is not noticeable as most TCP requests will wait for 30 seconds before being terminated (whereas in direct contrast, UDP will request a connection and not wait for a response). Sockets however are different as they provide a direct connection to the origin, and can be re-used to send traffic back and forth without needing to establish a new connection every time. However, if a remote socket does not receive a response in a set period of time, that session is closed and a new one needs to be opened.

This is a security mechanism to prevent the socket from being exploited and providing a direct route to the origin host.

Hiding your IP address is security through obscurity, and generally, bad practice

https://www.777networks.co.uk/what-is-security-through-obscurity-and-why-is-it-bad/

Hiding behind Cloudflare with no other protection in place is an effective air-gap, but once you circumvent the proxy IP (which is definitely possible), you are a sitting duck if you’ve relied on CF to protect you.

veronikya

I bought a lot of Nginx reverse proxy servers, but cf is too slow in my country, I set my main server nodebb to be accessible only via vpn network, and I think that’s fine if no one attacks the server!

phenomlab

@veronikya only accessible via VPN is very secure, and easily the best way to completely isolate the site from the rest of the Internet.

The downside of this is that your site isn’t publicly accessible without the VPN connection which would mean it falls under the umbrella of deep web. However, depending on the content, it may be what is required in order to keep sensitive information or topics secured.

DownPW

Hello

just for test, I wanted to test that configuration in my dev instance :

https://community.nodebb.org/topic/7930/using-cloudflare-with-nodebb

But I have this error uninterruptedly :

And I don’t know why

Nodebb config for socket.io :

Nginx config for socket.XXXX.XXXX

server {
	server_name socket.XXXXX.fr www.socket.XXXX.fr mail.socket.XXXX.fr;
	root /home/XXXXX/domains/socket.XXXX.fr/public_html;
	index index.php index.htm index.html;
	access_log /var/log/virtualmin/socket.XXXX.fr_access_log;
	error_log /var/log/virtualmin/socket.XXXX.fr_error_log;
	fastcgi_param GATEWAY_INTERFACE CGI/1.1;
	fastcgi_param SERVER_SOFTWARE nginx;
	fastcgi_param QUERY_STRING $query_string;
	fastcgi_param REQUEST_METHOD $request_method;
	fastcgi_param CONTENT_TYPE $content_type;
	fastcgi_param CONTENT_LENGTH $content_length;
	fastcgi_param SCRIPT_FILENAME "/home/XXXXX/domains/socket.XXXXXX.fr/public_html$fastcgi_script_name";
	fastcgi_param SCRIPT_NAME $fastcgi_script_name;
	fastcgi_param REQUEST_URI $request_uri;
	fastcgi_param DOCUMENT_URI $document_uri;
	fastcgi_param DOCUMENT_ROOT /home/XXXXX/domains/socket.XXXXX.fr/public_html;
	fastcgi_param SERVER_PROTOCOL $server_protocol;
	fastcgi_param REMOTE_ADDR $remote_addr;
	fastcgi_param REMOTE_PORT $remote_port;
	fastcgi_param SERVER_ADDR $server_addr;
	fastcgi_param SERVER_PORT $server_port;
	fastcgi_param SERVER_NAME $server_name;
	fastcgi_param PATH_INFO $fastcgi_path_info;
	fastcgi_param HTTPS $https;
	location ^~ /.well-known/ {
		try_files $uri /;
	}
	location ~ "\.php(/|$)" {
		try_files $uri $fastcgi_script_name =404;
		default_type application/x-httpd-php;
		fastcgi_pass unix:/var/php-fpm/16908800991403014.sock;
	}

	location / {
        proxy_set_header X-Real-IP       $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host            $http_host;
        proxy_set_header X-NginX-Proxy   true;
        proxy_set_header Upgrade         $http_upgrade;
        proxy_set_header Connection      "upgrade";
        proxy_redirect                   off;
        proxy_http_version               1.1;
        proxy_pass                       http://localhost:4567;
    }

	fastcgi_split_path_info "^(.+\.php)(/.+)$";
	location /cgi-bin/ {
		gzip off;
		root /home/XXXXX/domains/socket.XXXXX.fr/cgi-bin;
		fastcgi_pass unix:/var/fcgiwrap/16908800991403014.sock/socket;
		fastcgi_param SCRIPT_FILENAME "/home/XXXXXXX/domains/socket.XXXXXX.fr$fastcgi_script_name";
		fastcgi_param GATEWAY_INTERFACE CGI/1.1;
		fastcgi_param SERVER_SOFTWARE nginx;
		fastcgi_param QUERY_STRING $query_string;
		fastcgi_param REQUEST_METHOD $request_method;
		fastcgi_param CONTENT_TYPE $content_type;
		fastcgi_param CONTENT_LENGTH $content_length;
		fastcgi_param SCRIPT_NAME $fastcgi_script_name;
		fastcgi_param REQUEST_URI $request_uri;
		fastcgi_param DOCUMENT_URI $document_uri;
		fastcgi_param DOCUMENT_ROOT /home/XXXXXXX/domains/socket.XXXXXXX.fr/public_html;
		fastcgi_param SERVER_PROTOCOL $server_protocol;
		fastcgi_param REMOTE_ADDR $remote_addr;
		fastcgi_param REMOTE_PORT $remote_port;
		fastcgi_param SERVER_ADDR $server_addr;
		fastcgi_param SERVER_PORT $server_port;
		fastcgi_param SERVER_NAME $server_name;
		fastcgi_param PATH_INFO $fastcgi_path_info;
		fastcgi_param HTTPS $https;
	}
	listen x.x.x.x:443 ssl;
	listen [x.x.x.x::1]:443 ssl;
    ssl_certificate /etc/letsencrypt/live/media.XXXXXX.fr/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/media.XXXXXXXX.fr/privkey.pem;
 # managed by Certbot
}
server {
    if ($host = socket.virtuaverse.fr) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


	server_name socket.XXXXXXXX.fr www.socket.XXXXXX.fr mail.socket.XXXXXXx.fr;
	listen x.x.x.x;
	listen [x.x.x.x::1];
    return 404; # managed by Certbot


}

Cloudflare config :

phenomlab

@DownPW Does this issue manifest itself in Incognito mode?

DownPW

yes, it does

phenomlab

@DownPW You should simplify the nginx config - below a suggestion

server {
	server_name socket.XXXXX.fr www.socket.XXXX.fr mail.socket.XXXX.fr;
	access_log /var/log/virtualmin/socket.XXXX.fr_access_log;
	error_log /var/log/virtualmin/socket.XXXX.fr_error_log;
	listen x.x.x.x:443 ssl;
	listen [x.x.x.x::1]:443 ssl;
    ssl_certificate /etc/letsencrypt/live/media.XXXXXX.fr/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/media.XXXXXXXX.fr/privkey.pem;

	location / {
        proxy_set_header X-Real-IP       $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host            $http_host;
        proxy_set_header X-NginX-Proxy   true;
        proxy_set_header Upgrade         $http_upgrade;
        proxy_set_header Connection      "upgrade";
        proxy_redirect                   off;
        proxy_http_version               1.1;
        proxy_pass                       http://localhost:4567;
    }


 # managed by Certbot
}
server {
    if ($host = socket.virtuaverse.fr) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
	server_name socket.XXXXXXXX.fr www.socket.XXXXXX.fr mail.socket.XXXXXXx.fr;
	listen x.x.x.x;
	listen [x.x.x.x::1];
    return 404; # managed by Certbot
}

DownPW

@phenomlab done

phenomlab

@DownPW Also remove these lines and restart nginx

root /home/XXXXX/domains/socket.XXXX.fr/public_html;

	index index.php index.htm index.html;

DownPW

Same

DownPW

I see this on start log nodebb

phenomlab

There’s more of an issue here - try to change any CSS or JS in the ACP, and you’ll see that it does not save.

DownPW

???

phenomlab

@DownPW Now working for me in Incognito. Can you check

DownPW

@phenomlab said in NodeBB socket with CloudFlare:

There’s more of an issue here - try to change any CSS or JS in the ACP, and you’ll see that it does not save.

due to socket.io configuration in nodebb config.json file

Actually I have delete socket.io block and change CSS and save is good.

phenomlab

@DownPW Ok, but that now means you should not need the socket A record anymore because it’s not used. From the logs, the socket is running on the site’s URL.

DownPW

normal that it is not used (A record) @phenomlab because there currently, I do not use it because the socket.io block is removed from config.json.

I’m just in normal mode with Cloudflare :

I can put it back if you want ?

phenomlab

@DownPW It seems to be working fine without it, so I’d leave it. I see zero socket errors, so all good.

DownPW

because I’m alone on the server.

The goal is to try to market this method before putting it into production where i have a lot of errors

And we can see that it doesn’t work when I try to reroute the web sockets in non-proxied mode. (socket error, no save when chnage in ACP, etc…)

I don’t know if I can make myself understood. @phenomlab

NodeBB socket with CloudFlare

Related Topics

build nodebb Warning in entrypoint size limit

Optimum config for NodeBB under NGINX

NODEBB: Nginx error performance & High CPU

Top Ranked Forums

Plugin reaction Bug

what does sound/mute button do?

NodeBB slow after DB recovery

[NODEBB] Help for my custom CSS

NodeBB socket with CloudFlare

Related Topics

Individual Categories