docs icon indicating copy to clipboard operation
docs copied to clipboard

Reverse proxy configuration for apache

Open WTFThatPerson opened this issue 7 years ago • 8 comments

That sample configuration ProxyPass /syncthing/ http://localhost:8384/ <Location /syncthing/> ProxyPassReverse http://localhost:8384/ Require all granted </Location> isn't enough, 'cos it doesn't prevent from host check error; You should to add HeaderRequest there, i.e. ProxyPass /syncthing/ http://localhost:8384/ <Location /syncthing/> ProxyPassReverse http://localhost:8384/ HeaderRequest set Host 127.0.0.1
Require all granted </Location>

WTFThatPerson avatar Mar 17 '18 19:03 WTFThatPerson

Apparently setting Host as localhost/127.0.0.1 is bad idea. The preferred workaround when behind a reverse proxy is to set <insecureSkipHostcheck>true</insecureSkipHostcheck> (within the <gui .. > </gui> section of the Syncthing config.xml).

See discussion in #401

JedMeister avatar Jul 12 '18 20:07 JedMeister

I'm not sure I understand clearly what do You talking about. As per my understanding, for reverse proxy given, HeaderRequest modifies request header on the way "proxy -> target" only. i.e. inside server. Why do You think InsecureSkipHostcheck turning off host checking globally is "preferrable"?

WTFThatPerson avatar Jul 13 '18 07:07 WTFThatPerson

I'm just repeating what the devs mentioned on my similar issue https://github.com/syncthing/docs/issues/401 (same issue, just with Nginx rather than Apache).

E.g. see https://github.com/syncthing/docs/issues/401#issuecomment-404088454 and/or https://github.com/syncthing/docs/issues/401#issuecomment-404423182 and/or https://github.com/syncthing/docs/issues/401#issuecomment-404646596

Or perhaps more clearly (forcefully?): https://github.com/syncthing/docs/pull/402#issuecomment-404421866 (on the PR I opened to change the docs).

JedMeister avatar Jul 13 '18 07:07 JedMeister

Again, I don't understand all that arguments. InsecureSkipHostcheck completely disables host name checking, so how it can better way against HeaderRequest? One can discuss what he likes more: HeaderRequest or InsecureSkipHostcheck, but it's not a reason to give advices at a confident manner

WTFThatPerson avatar Jul 13 '18 09:07 WTFThatPerson

What if syncthing behaves differently in terms of security when it knows the requests are not coming from local host? Is it then better to lie that the requests are coming from local host?

I am not saying syncthing does behave differently, I am just raising a hypothetical question.

AudriusButkevicius avatar Jul 13 '18 10:07 AudriusButkevicius

Well, what we ended up, is some kind of IP filtering, so, we talk about firewall functionality, right? But wait a minute, it's all about lightweight syncing program with small resources consumption, isn't it? :) At another hand, none use reverse proxy just for nothing, it assumes we have use another proxy clients on device in parallel. And every other program has exatly same problem with DNS binding vulnerability, so we end up with firewalling inside every program which is nonsense, of course. If one setting up reverse proxy, he can use web firewall, say ModSecurity, and simple something like SecRule REQUEST_HEADERS:Host "!^www.example.com(:[0-9]+)?$" "id:1, phase1 t:none, nolog, deny, status:403" cures everything with ease, I don't mention about extra security with CRS packet. And BTW, TLS breaks malicious connection attempt, because it won't decrypt data without certificate. So, IMHO, You can leave syncthing docs mostly untouched, with one adding, something like "we highly advise against using reverse proxy combined with plain http, but with https only" with explaining of security breaches

WTFThatPerson avatar Jul 14 '18 10:07 WTFThatPerson

Whats wrong with a firewall in every application? Are you suggesting to leave ourselves vulnerable if we don't run behind a proxy?

Anyways, if the proxy has mitigation for dns rebinding, then it doesn't matter which you do.

AudriusButkevicius avatar Jul 14 '18 11:07 AudriusButkevicius

Look at it this way. Syncthing treats requests differently when bound to localhost and not bound to localhost - at the moment specifically to protect against DNS rebinding, in the future potentially in other ways as well. When running behind a reverse proxy the requests are not coming from localhost, despite how it may seem to localhost-bound Syncthing. They therefore fail the checks. This is clear to everyone involved. You then have two possible solutions:

  • Lie to Syncthing by telling it the request is originating from localhost. (i.e., set Host: localhost), or
  • Tell Syncthing to not enforce security related to localhost requests (insecureSkipHostCheck=true).

The effects of the first are unclear, especially in the face of future development. The effects of the second are specified - you're telling Syncthing to not concern itself where the request is coming from, as you're taking care of that yourself. This is the cleaner option.

calmh avatar Jul 14 '18 14:07 calmh