I keep my forum’s server behind cloud flare due to a large amount of attacks against the site. The link previews and emails can leak the server’s backend IP Address. The email issue was resolved by setting up a SMTP relay that strips headers (if the user pulls email headers to get the IP, they get the relay and not the forum’s IP). Is there a way to make the link previews go through a proxy server?
1 Like
i asked this question about a month ago about link previews and got no help 
1 Like
Hopefully someone from the team is able to help us soon.
1 Like
Purely out of curiosity… How does previewing a link leak ip info?
From what I understand discourse fetches the link server side to generate the preview. Post a malicious link controlled by attacker, check server access logs, get IP address attack and site go down. Easy peasy
It was so easy grabbing the IP of Discourse Meta Backend from image preview using an IP Logger. For obvious reasons I’ve redacted Discourse’s backend IP Address from the images showing evidence.
Proof:
1 Like
Ah. Then it is not a discourse issue. It is a network setup issue for your server. Your server needs to set up networking with a proxy. Then anything accessing the network, including discourse, will automatically go thru the proxy.
2 Likes
Yes you will need to set up a proxy for outgoing traffic on your server this has nothing to do with us.
1 Like
Alright so how do configure Discourse to connect to the proxy? Where do I configure proxy settings. If I could just forward traffic to go through SOCKS localhost:9050 I could route through Tor without an issue.
Your comments are very confusing and doesn’t look like it is related to a proxy at all.
A proxy is for OUTGOING traffic. localhost:9050 is INCOMING, unless you mean all your out-going traffic is going out via port 9050.
Check careful the answer: You don’t configure Discourse to connect to the proxy. You configure the SERVER to use a proxy for OUTGOING connections.
Provide instructions? Also localhost:9050 exits through Tor.
My suggestion for you is to get a sysadmin person to look at your network setup on the SERVER. Nothing really to do in Discourse here…
1 Like
Is has everything to do with discourse, it’s not an unreasonable request to ask where to configure proxy settings. As for sysadmin stuff I’ve never configured a server to exit through a proxy before, it’s site policy to not grant 3rd parties access to SSH.
I see what you’re asking here.
The short of it is that Discourse itself has no way to tell it to use a proxy for outbound connections, thought it appears Net::HTTP has the capability to automatically use the http_proxy environment variable, which (in some cases) should serve your needs.
I would recommend the following steps:
- set up an offsite https proxy
- configure your Discourse server’s firewall to reject (and LOG!) outbound connections from Discourse
- deploy Discourse with the http_proxy
- monitor your firewall logs so you can watch for outbound connections you didn’t think of (e.g. DNS) and whitelist them or adapt the section of the code from where it’s called
This will probably take some effort to get working, alternatively you could tunnel outbound traffic via a tunnel to an offsite host.
Since you already have a SOCKS proxy set up, maybe you can add outbound firewall mangling rules to transparently shunt requests to a squid proxy that then uses SOCKS for outbound requests?
7 Likes
Thank you for sharing this. Would you mind sharing how to set the http_proxy environment variable? I will be configuring Privoxy to forward requests to the Tor Process so outbound traffic is completely anonymous and will not expose my forum’s backend IP Address. Information on setting that environment variable would be great though 
You need to set it in the env section of your instance’s .yml file if using discourse_docker. Otherwise, just set it in your startup script.
I got CURL to connect over Tor so my real server’s IP Address won’t leak. I’m working on editing app.yml right now.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && gem update bundler failed with return #<Process::Status: pid 269 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:108:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"web", "cmd"=>["gem update bundler", "chown -R discourse $home"]}
941587b32cdd671254567f75ce8ca877639de1bb60ee101fa31a4e3d947da140
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one
root@discourse:/var/discourse#
Getting that error when I try to rebuild. What happened?
Goes away when I remove the proxy enviroment variables.
But really, do you really NEED all this? I haven’t seen anyone go to such lengths to mask their IP address before… Why not use a dynamic IP and be done with it? Or, get your server behind a good gateway with a good firewall and just allow the one port through.
If your machine is exposed to the Internet with a fixed IP, eventually your IP WILL be found. It is just a matter of running an IP scanner.
No, this isn’t so. The entire premise of CloudFlare is that it works great against even nation state attacks as long as they DO NOT figure out your real IP.
4 Likes