Question about reverse proxies and WAFs

Hi all,

     How are you?

First of all excuse my english as it is not my mother tongue.

I’d like to ask a rather general question which is not nginx specific:
In my new job they use an Apache webserver running mod_proxy as a
reverse proxy that works as the single entry point from the outside
for all the apps that work in the LAN. That is, the webserver is in
DMZ when they need an app published outside, the networking guys give
permission on the firewall from the internal server to the DMZ reverse
proxy which in turn is NAT’ed to the internet.

That reverse proxy does two things:

First it encrypts traffic, or it seems so, that is: The vhost
listening on port 443 is the one that does all the proxy pass to the
backend servers, so if anyone points their browser to
https://outside-address/app they’d go directly to the appserver. But
if they to http://outside-address/app, using mod_rewrite, they’re
redirected to https://outside-address/app.

And second, it runs mod_security with the OWASP rules to act as a Web
Application Firewall.

My question is this a good setup for a reverse proxy + WAF?

As far as I’m concerned if you hit directly port 443 and get
redirected to the app, no modsecurity inspection is made, because the
request is SSL encrypted, right? The only modsecurity inspection would
be when you hit port 80 and get your address rewritten to https, is it

Also, I don’t know if nginx does the same, but for requests to be
proxied by Apache it seems that they must share the URL pattern with
the app server, that is:

It seems that you CAN NOT proxy http://outside-address/my_app to
http://server_in_the_lan_hosting_my_app/ BUT you must do:

http://outside-address/my_app/ proxied to http://lanserver/my_app/ if
the URL part “my_app” isn’t matched it won’t redirect requests to the
backend. Is this correct?

And last, I’m writing this here because I tried to migrate this to
nginx once, but it kept crashing (Not even finishing to start up) with
the OWASP core rules.

Does it makes sense SSL rewrites/termination on a reverse proxy/WAF?

Can nginx handle proxing requests that won’t match URL patterns? Like
I mentioned above?

Does anybody run nginx + OWASP rules for mod security?

Thanks in advance and sorry for the bothering,

Buenos Aires

With respect the ModSecurity and the CRS, the current nginx
implementation of ModSecurity is still pretty buggy and likely won’t get
any attention. It’s known to cause segfaults and server-side errors
during requests. You’d be better off looking at the libmodsec v3
integration, which is still in development.

There is a version of modsecurity for Nginx - - however it tends to cause
random mysterious problems including segfaults so maybe not what your
looking for.

There are also several WAFs built upon Openresty (nginx + luajit at however I haven’t set any of them up yet so I can’t
on their production readiness.

If you do have a WAF running I’d let to handle both SSL and non-SSL
connections. SSL isn’t the barrier it used to be, in fact there is a
to stomp out plain http altogether, and the last few months I’m
seeings bots, crawlers, and scripts adapting and connecting via SSL.

On Sun, Apr 24, 2016 at 11:28 PM, Francisco V.
[email protected]

for a nice and simple*) but yet powerfull WAF-solution for nginx you
might want to try naxsi

*) simple in terms of: easy to setup, easy to maintain, easy to adjust



Posted at Nginx Forum:,266350,266356#msg-266356

There are also several WAFs built upon Openresty (nginx + luajit at however I haven’t set any of them up yet so I can’t
comment on their production readiness.

Speaking as the author of one of these (lua-resty-waf,, I can tell you that it’s
definitely a production-ready project. lua-resty-waf is designed to
direct translation of ModSecurity functionality, and allows you to port
your existing ModSecurity ruleset, obviating the need to rewrite your
in a new syntax.

Very cool! lua-resty-waf is actually at the top of my list of WAFs to
as soon as I finish deploying openresty everywhere.

On Mon, Apr 25, 2016 at 11:09 AM, Robert P. <