Discourse Link previews through a proxy server?

(Nathaniel Suchy) #1

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?


i asked this question about a month ago about link previews and got no help :facepalm:

(Nathaniel Suchy) #3

Hopefully someone from the team is able to help us soon.

(Stephen Chung) #4

Purely out of curiosity… How does previewing a link leak ip info?

(Nathaniel Suchy) #5

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

(Nathaniel Suchy) #6

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.


(Stephen Chung) #7

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.

(Jeff Atwood) #8

Yes you will need to set up a proxy for outgoing traffic on your server this has nothing to do with us.

(Nathaniel Suchy) #9

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.

(Stephen Chung) #10

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.

(Nathaniel Suchy) #11

Provide instructions? Also localhost:9050 exits through Tor.

(Stephen Chung) #12

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…

(Nathaniel Suchy) #13

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.

(Michael Brown) #14

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?

(Nathaniel Suchy) #15

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 :slight_smile:

(Michael Brown) #16

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.

(Nathaniel Suchy) #17

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.

(Nathaniel Suchy) #18
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"]}
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

Getting that error when I try to rebuild. What happened?

Goes away when I remove the proxy enviroment variables.

(Stephen Chung) #19

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.

(Jeff Atwood) #20

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.