Kong > Nginx > Owasp's mod_security - Google says: 404

[Gerard Petersen]

Hi all,

After some googling I found that there’s as good as nothing to find on the combination of OWASP’s Mod security for Nginx and Kong. Does that mean:

- it’s not needed?

(kong handles this, I just need to read the docs better)

- should modsec be setup seperately (in front) of kong?

(Do what you like)

- Do people don’t care about this level of security?

(Looking wonderous)

- Are people waiting for somebody to step up and make this happen?

(Treading carefully)

- Is it even doable to build a kong+nginx+mod_security?

(To much time on your hands?)

- Just buy the black box (container) and don’t ask questions?

(Looking frightened) 

Anybody care to comment?

Thank a lot!

Regards,

Gerard.

[Sorin Manolache]

Hello,

It is doable. I've attached my debian/rules file that builds a debian
package (for debian/unstable or ubuntu/trusty) containing the openresty
nginx with mod_security.

Why deploy mod_sec _in front_ of kong? You may have many APIs behind
kong and each can come with different security requirements. For
example, let us assume that you have two APIs on two different backends
behind kong. One of them has no database whatsoever, so SQL injection
rules make no sense for that API. The other has an SQL database and SQL
injection rules do make sense. If you deploy mod_sec in front of kong
then you'll include the SQL injection rules in your mod_sec
configuration. That would be a waste of response time for the requests
that are routed to the database-less API.

So I would rather advocate deploying mod_sec _behind kong_, on each
backend, and tune the rules to the needs of each backend.

--
Sorin

>
> Thank a lot!
>
> Regards,
>
> Gerard.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Kong" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to konglayer+...@googlegroups.com
> <mailto:konglayer+...@googlegroups.com>.
> To post to this group, send email to kong...@googlegroups.com
> <mailto:kong...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/konglayer.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/konglayer/c515938a-39f4-4c4e-b723-b80ba25413dc%40googlegroups.com
> <https://groups.google.com/d/msgid/konglayer/c515938a-39f4-4c4e-b723-b80ba25413dc%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Gerard Petersen]

Dear Sorin,

Thanks for the response, and good point on the 'behind kong' setup, to avoid the performance hit. Do you then run a container with just nginx and the specific rule set in there?

Regards,

Gerard.

[Sorin Manolache]

On 2016-07-22 15:08, Gerard Petersen wrote:
> Dear Sorin,
>
> Thanks for the response, and good point on the 'behind kong' setup, to
> avoid the performance hit. Do you then run a container with just nginx
> and the specific rule set in there?

"There" = on the backend API? It depends on the backend, it could be an
apache server, not an nginx server. Then the container contains the web
server (nginx or apache), with mod_security, and the backend application
running on top of the web server.

If "there" is the proxy (kong), then we run a container with
nginx+mod_security+kong. We didn't use the container provided by
getkong.org, nor the debian package that contains all dependencies.
We've built our own nginx and kong packages from sources and then
created a container with our own packages. We did that only to assess
the response time degradation when enabling mod_security. I don't
remember the numbers (I _think_ it was something around 30% response
time degradation), so we decided to disable mod_security on the kong
proxy. We have not yet taken a decision about activating it on the
backend. We hope to have a smaller degradation because we could tune the
mod_security rule set to the backend application but I'm not holding my
breath.

Sorin