Reverse Proxy Configuration
When working with reverse proxies and load balancers, the typical setup looks like this:
- The Connection between the client and the reverse proxy is using https.
- The Connection between the reverse proxy and the LiquidFiles system is using http.
With the default configuration to Force https connections, the LiquidFiles system will see all connections as coming from the proxy (10.1.2.2) with http, meaning that you will get into a redirect loop as it's trying to redirect the clients browser to https, but the connection keeps coming back on http. If you use https between the reverse proxy and the LiquidFiles system, you can use the "Force https" setting.
To make sure that the LiquidFiles system can see the end clients ip address, and use https everywhere, please update the Admin → Network configuration like this:
By setting the Protocol to "Prefer https", all the links and redirects by the system will use https, but it will not check for the presence of a https connection and always try to redirect http to https. If you want to ensure that all traffic uses https, please update the reverse proxy with the configuration to redirect http connections to https.
The trusted proxies configuration will listen for the "X-Forwarded-For" http header from the trusted proxies so when the LiquidFiles system displayes the log, the connection on the map, and anywhere else where it uses the clients ip address - it will use the clients real ip address (18.104.22.168 in the example above) and not the proxy's (10.1.2.2). Most reverse proxies will automatically set the X-Forwarded-For header, but if it doesn't please make sure you add this configuration to you reverse proxy.
Will using a Reverse Proxy improve my security?
Mostly — No, our experience is that you're likely going to make things worse with a reverse proxy.
Going back a few years, common knowledge was that using a reverse proxy, any reverse proxy, would improve security for all web server and web services. This is not true any more. LiquidFiles, that uses a modern web server configured according to modern security standards is more than capable of residing on the hostile Internet without any form of reverse proxy.
There are basically two types of reverse proxies. Simple
reverse proxies and
Web Application Firewalls (WAF).
A Web Application Firewall will look at all the traffic and has the capability to intercept common web application threats
and block in real time.
Configuring any Web Application Firewall will take weeks for each application that you on-board. Some have a builtin learning capability so that you can whitelist things that it has caught that's considered false positivies. If you use a Web Application Firewall, it should prevent attacks from reaching the LiquidFiles system and give a lot more detailed logging over the attacks and will therefore improve the overall security as if nothing else you'll get increased visibility.
If you use a simple reverse proxy that cannot look at specific web threat patterns and highlight for instance if any forms are not using Cross Site Request Forgery protection, likilehood is that both security and performance will suffer.
Session Cookie Secure Flag and HSTS
Two things that often come in security reviews when using reverse proxies is that the session cookie secure flag is not set and that HSTS is not configured. The session cookie secure flag tells the browser that this cookie can only be used for https sessions and not http sessions. In LiquidFiles, this is enabled if you configure the http protocol as "Force https". That's the only setting that will guarantee that the client will always use https (this is the default setting and on default the session cookie secure flag is set). If you follow a traditional reverse proxy configuration, you'd use https between the client and the reverse proxy and http between the reverse proxy and the LiquidFiles system. In LiquidFiles you configure a protocol setting other than "Force https", and since LiquidFiles then can no longer guarantee that the client will always use https, and indeed what happen in this configuration, and we can no longer set the session cookie secure flag in LiquidFiles.
It's similar with HSTS. HSTS is a function that tells client that until a specified timeout you are only permitted to connect to this server using https. The recommended timeout and the timeout that LiquidFiles uses is 1 year. Please see the LiquidFiles HSTS documentation for more information about HSTS. Similarly to the session cookie secure flag, LiquidFiles cannot tell clients to force connections over https unless you configure LiquidFiles with the protocol setting to "Force https".
In both of these cases, you have two options, either use https all the way to the LiquidFiles system, or you will have to configure your reverse proxy to set the secure flag for the session cookie, and configure HSTS in the reverse proxy.
Web Security Testing
A simple way to test the web security configuration is to use SSLabs SSL test on the LiquidFiles system. A default configured LiquidFiles system will receive an "A+" score. If you don't receive an "A+" score when using LiquidFiles through a reverse proxy, you have made LiquidFiles less secure than if you didn't use a reverse proxy.
Our experience is that most reverse proxies are not configured for optimum security and have less secure default configuration that what LiquidFiles has. With the default configuration on both, security (and performance) will therefore be better by not using a reverse proxy. If you implement a Web Application Firewall, take the time to both configure it properly and have a system for ongoing monitoring, you'll block attacks before the reach the web application, get an incrased visibility of the threats and overall increased security. But with a simple reverse proxy that don't inspect the traffic, the best you can really hope for is that you don't make things worse. Use the SSLabs SSL test and test upload and download speed with and without the reverse proxy and decide what's best in your instance.