Considerations on DMZ Design in 2016, Part 2: A Quick Digression on Reverse Proxies

This is the second part of a series with considerations on DMZ networks in 2016 (part 1 can be found here). Beforehand I had planned to cover classification & segmentation approaches in this one, but after my little rant on how “the business” might approach & think about reverse proxies in the first part, I felt tempted to elaborate a bit further on this particular topic. I kindly ask for your patience 😉 and will digress a bit for the moment.

So today’s topic is “reverse proxies” and, as usual, let’s start with some definitions. What does “proxy” mean?
From a general language perspective, Merriam-Webster defines (amongst others) as follows:

• “the agency, function, or office of a deputy who acts as a substitute for another”

This gives an initial indication what a proxy is about (“acts as a substitute”). Moving into the space of network security we find the following in “Building Internet Firewalls” (commonly used in this series as a kind-of classical reference):

“A proxy server for a particular protocol or set of protocols runs on a dual-homed host or a bastion host: some host that the user can talk to, which can, in turn, talk to the outside world. The user’s client program talks to this proxy server instead of directly to the ‘real’ server out on the Internet. The proxy server evaluates requests from the client and decides which to pass on and which to disregard. If a request is approved, the proxy server talks to the real server on behalf of the client and proceeds to relay requests from the client to the real server, and to relay the real server’s answers back to the client.”

While, interestingly, ISO 27033-1 doesn’t mention proxies at all, ISO 27033-4 states:

“[An] application proxy service has full visibility at the application layer and can accordingly see the granular details of each attempted connection up front and implement security policies accordingly. Application proxy services also feature a built-in proxy function – terminating the client connection at the application gateway and initiating a new connection to the internal protected network. The proxy mechanism provides added security because it separates the external and internal systems and makes it more difficult for attackers on the outside to exploit
vulnerabilities on systems internally.”

From these – and adding a bit of practitioner’s perspective ourselves 😉 – we can extract/derive the following properties of a “proxy”:

• a proxy provides some separation/isolation between trusted and less trustworthy networks.
• its role & position (within a network) foster providing additional security services like ensuring protocol-level/semantic correctness or performing higher-level filtering (incl. stuff such as content filtering, URL filtering and the like).
• its role & position can be used to provide additional (“not security-related”) functions like content caching. (actually that’s what most users have in mind when it comes to proxies…)

Thinking about these, an obvious but sometimes slightly overlooked implication becomes clear: a proxy itself must be highly trustworthy (which is why it was, in old times, sometimes called bastion host). It is (or at least: should be) expected to have a “higher chance of survival against compromise“ than other systems it helps to protect. This means that, amonst others, the following security processes might be relevant in the operational context of proxies themselves ;-):

• Hardening & patching
• Security quality assurance (e.g. by periodic security assessments)
• Proper handling of privileged accounts

[some readers from large corporate environments using reverse proxies might already start scratching their heads…]

To conclude the lengthy ramp-up here I still owe you a definition of “reverse proxy” – let’s just proceed with the following: while a traditional (“forward”) proxy usually protects trusted clients when they establish connections to untrustworthy servers in the Internet, a reverse proxy is supposed to protect trusted servers when they receive connections from less trustworthy entities, e.g. from the Internet or from business partner networks.

The additional security services a “reverse proxy” can provide encompass:

• “SSL Offloading“ / Termination of TLS connections (which, btw, might create interesting situations with [wildcard] certificates. more on this, maybe, in another post).
• URL Rewriting
• Load Balancing
• (“Centralized“) Authentication
• Serving static content / caching
• Compression
• Curbing of requests which are forwarded to the web servers (the type of stuff Apache mod_cband does). Some people might call this “Anti-Dos” and this might be true, for certain servers ;-).

Things to Keep in Mind when Operating Reverse Proxies

Now let’s assume an organization uses reverse proxies. Let’s further assume that those, while sitting in “some DMZ segment” themselves, sort of serve as a substitute for “the DMZ-oriented design approach”. That means that they are used to enable outside access to applications actually living (and staying) in the corporate LAN/intranet as – according to the application owners – those applications can not be put “into a DMZ” due to their complex interactions with other systems like database backends or the migration can not be done because tight project schedules or … yada yada yada.
Such a setting pretty much reflects what we increasingly see in corporate environments. Point then is: what are the implications from a security architecture and governance perspective?

Foremost, let’s look at the two main purposes of “a DMZ” which we discussed in the first part. Those are:

• A system placed in a DMZ can itself expect a certain level of infrastructure based protection.
• At the same time a system’s placement (in a DMZ) is supposed to provide some protection for other systems, as lateral movement is made harder (once the system becomes compromised).

Looking at the second one it becomes clear that in such a setting (where RPs are used to enable connections to applications in the corp intranet) they must still provide (their share of) a contribution to inhibiting lateral movement. This can (and should!) happen through configuration measures like

• Inhibition of shell uploads. Amongst others this can be done by
• Restriction of HTTP verbs (any need to allow anything else than GET & POST? ok, ok I hear you guys running RESTful web services…). Usually this is a good and easy measure supported by pretty much all platforms.
• Prevention of OS commands in a database context (e.g. stuff like xp_cmdshell in MS SQL setups). Admittedly, this might require a level of inspection capabilities not available on the devices in question. But you should still think hard & deep about it: is there stuff to deny for *all* inbound HTTP[S] connections?

In general the ability and actual implementation of a (operationally) feasible blacklist based approach on a reverse proxy is considered helpful ;-).
[for the record, as the question will inevitably be raised: no, in the present context whitelisting rarely works in a way that really provides security benefit – for reasons laid out here – which in turn is why those once-hyped, expensive “reverse proxy on Linux with a nice GUI” appliances called WAFs pretty much never have a reasonable sec benefit to cost incl. OPEX ratio]

Reflecting a bit on the use case reverse proxies offer in a setting as described above, it turns out that in quite a few environments RPs actually fulfill a role which, ten to fifteen years ago, was previously held by stateful firewalls: they essentially serve as a main entry & security control point for “services offered to the outside world”. At that time in the past one had to approach “the firewall admins to create rules based on destination IP and port numbers”, nowadays – with everything running over HTTP anyway – one has to “ask the guys operating the reverse proxies to activate a URL” (and it might not even be needed to touch any [traditional] firewall rule as the to-be-published application runs on one system hosting several applications at the same time. Does this sound familiar? 😉

The Similarity of Stateful Firewalls in the Past and Reverse Proxies Today

In the following table I attempt to list some similarities between the two:

 

 

 

 

 

 

 

What Does All this Mean from a Governance and Operations Perspective?

The answer is quite simple – ask yourself: do all those (security) processes applied to traditional firewalls have the same maturity level when looked at in the context of the reverse proxies? The following might come to mind here:

• Requesting a rule (which might include templates providing some upfront [security] education for the requesting party), e.g. does this happen through a ticket system or via “quick e-mail to RP admin”?
• Rule approval (=> processes & parties involved. Remember the times when corp infosec was part of the firewall change workflow? Do you have [or want] sth similar for your RPs?).
• Documentation (cough*) and periodic review of rules.
• Capacity planning of operations personnel incl. development & maintenance of their skills.
• Proper integration of security-relevant log information into monitoring processes. If you want to feed the RP logs into your SIEM (and, taking the above into account, you should), you MUST carefully tune the type & amount of information you transmit from the RPs in direction of the SIEM (or the sales guy from your SIEM vendor will have a new Porsche soon…).

These are just some examples. The main step is to understand the role of RPs within your security architecture and to have the proper associated processes in place.

tl;dr

Yes, I should have put this on top of the post… still I hope you enjoyed reading. 😉
Let me quickly summarize some of the above points:

• keep in mind that a proxy itself must be able to withstand attacks with higher resistance than the hosts-to-be-protected. Perform periodic security quality assurance activities.
• once reverse proxies are used to bypass “proper placement in a DMZ” the (now potentially lost) “prevention of lateral movement” aspect must be paid attention to & compensated for (e.g. by certain configuration measures on the reverse proxy).
• in many environments reverse proxies nowadays fulfill a role once implemented by stateful firewalls. Do you have proper processes to reflect their contribution?

That’s it for today. Let’s see what the next part of the series will bring. 😉

Thank you for your valued attention & happy to receive any feedback.
Have a good one everybody

Enno