Is authentication mandatory when setting up a reverse proxy?

Question

I have never deployed a reverse proxy before and i was wondering if it is mandatory from a security perspective, to ensure only authenticated requests reach my web application server past the DMZ?

My web application server which runs linux tomcat stack, has all the mandatory security and firewall infrastructure and can authenticate its own requests. We just dont want to host it in the DMZ since it does not always run the latest OS or tomcat instance.

Googling "reverse proxy best practices" or "reverse proxy security best practices", did not turn up any recommendations to mandatorily enable authentication at the proxy.

What are the guidelines on this and what is generally practiced in the field ? I would appreciate all answers and especially so from folks who have actually deployed reverse proxies in a security conscious environment like banks etc ...

Thanks in advance.

Answer 1

I think there is no general guideline on that topic. I have set up multiple reverse proxies in different areas and sometimes used authentication and sometimes not, heavily depending on the actual use case.

From your question

My web application server which runs linux tomcat stack, has all the mandatory security and firewall infrastructure and can authenticate its own requests.

i would deduce that authentication in your proxy would not make a lot of sense when your server is already doing that. Including authentication in your reverse proxy makes sense when you want to create a secure connection between a client and otherwise unsecure server. When your server already is secure, i do not see any reason to add another layer of security.

I have never deployed a reverse proxy before and i was wondering if it is mandatory from a security perspective

It is definitely not mandatory. It is of course good practice to secure resources which would otherwise be totally open. So, of your server is already 'secure' and authenticating requests, i would not add another authentication instance.

Answer 2

I worked for many years as an Infrastructure engineer for a company on the fringe of Th banking industry moving around large sums of money between lots of people.

Our systems designs never required authentication from the proxys, although these were not externally reachable (ie behind NAT), although there was user authentication happening in the app.

This setup was never an issue, and there were a number of audits from external auditors, and external experts, in addition to internal scrutiny- no one ever brought this up as a potential issue.

Maybe relevant questions to help clear your mind, as the answers can differ depending on deployment and may inform your decision -

1. What is the consequence of a user bypassing the reverse proxy? Why is the proxy the best place to secure against the threat?

2. How can the systems behind the secure proxy be reached and is there a more appropriate place to put the end nodes? Does it make sense to secure the proxies in ways other then authenticating them?

Answer 3

A consequence of an unauthenticated reverse proxy is that complete set of requests that hit the proxy pass up the network transparently to the upstream server. Though this might fail to authenticate, it can be used as DoS attack on the server.

DDOS - Attacks on upstream servers

Depending on your implementation, (in our case it was) the proxy can be more efficient or take this load off your upstream server to fail the invalid requests and thus allow the upstream server to be more available to other clients. This is especially true if the reverse proxy is not the only ingress point for requests to the server in question or if there is an efficiency difference between the proxy and your upstream server. (eg nginx with lua vs tomcat)

DOS - Attack on the proxy

When authentication is done upstream, the proxy has to do MORE work (2-3 systems call atleast) to read and write data to send and recieve all the requests to/from upstream. Hopefully your authentication done at the proxy is lighter. If so, sending all this spurious data upstream, EVEN if it does not cause your upstream to fail, will cause the proxy to be much more loaded and cause a DOS on the proxy & will affect all other services exposed using the same proxy.

All this traffic which travels upstream, will also likley put a pressure on the proxy -> upstream link, especially this is not over LAN, depending on the size of the attack

Reacting to vulnerabilities

A proxy setup is much fewer number of boxes to manage, compared to say an upstream solution which runs on scores of VM's or boxes. If the core infrastructure for the solution has a vulnerability, the proxy without authentication just exposed your entire org to a zero day vulnerability, since these sort of solutions cannot be patched in a day, let alone convincing the companies to release a patch. However the proxy is entirely under the IT control and can be patched immediately to prevent any further vulnerabilities. The proxy effectively is a HUGE step up in security, if kept patched and uses authentication at the edge.

Risk of Open Proxy

A typical problem with proxies is that misconfigurations sometimes creep in, thus allowing the proxy to expose unintended upstream servers or locations. Without an authentication, this proxy thus starts acting like an open reverse proxy which is a real threat to the corporate LAN & even the general internet, since that is used by bad actors to hide their actual locations for attacks on other targets. Open proxies (wrt redirects) are considered to be universally bad.

By ensuring your reverse proxy has authentication, the risk of creating an open proxy becomes much more smaller.