Reverse Proxy + WAF

Question

AS part of network design, I am implementing a HTTP Reverse proxy as well as a WAF.

The HTTP Proxy, I am thinking about terminating SSL, on either the outer firewall - so the WAF can insect the layer 7 traffic.

Outer Firewall --> WAF --> HTTP Proxy ---> Internal Network / Public zone DMZ

Any machine on the internal network / public facing DMZ then would divert all traffic through the Reverse proxy, and then back out through the WAF. Yes.

My question is - is this the best way to deploy a WAF with the HTTPS reverse proxy, so do I need to go back to studying?

Answer 1

You haven't defined the website/application. Is it mutable? - if it's mostly static content then a few web-server rules could drop any malicious traffic.

If it's customer facing/dynamic... do you want all that traffic hitting your network?; a better option may be to push it into the cloud, have a WAF+load-balancing virtual appliance infront of your elastic server cloud. WAF will protect from data integrity attacks (eg. SQL injection); load-balancing/elasticity from DOS.

If you do have it local, you'll have to contend with bad queries ( rejected by WAF ); bad actors ( block by IP; based on WAF logs ) and ultimately the success of the service - can legitimate traffic overwhelm your internet connection and adversely affect other business processes?

Answer 2

Your Proxy's purpose is to act as an intermediately between the servers in your DMZ and clients of those servers on the internet. It can act in a security role by intercepting header requests and it can act in a performance role by load balancing and optimizing.

The majority of on-premise WAF's are based on reverse proxies but have updated software and more powerful hardware. Your WAF's purpose is to mediate the HTTP traffic coming from the web into your DMZ. It is (very) likely already be able to perform all of the functions that your reverse proxy can.

SSL must be terminated at the WAF or the outer-firewall depending on the function of the outer-firewall. NGF = Yes, Other = No.

Another consideration is the architecture. On-premise WAF's are expensive. They are typically priced on throughput so depending on the size of the network it may be wise to remove the Internal LAN from the WAF, especially since they should be no incoming connections directly to the Internal LAN.

Answer 3

I would say that it depends on the type of data you are transferring and the regulations that may apply, terminating the TLS connection and then transferring the data in clear will be a violation of some regulations (e.g. PCI-DSS).

There is also the privacy concern, do you mind if the data travels in clear from whenever you put the TLS termination point to your web entry point?

You may do TLS termination at the WAF and then open another TLS connection to your endpoint so the data is not traveling in clear but you may inspect the flow, you may even do both waf+reverse proxy with apache and modsecurity for free. There is a GitHub docker version that can be set up in minutes (modsecurity-crs-rp).