Re: Interests in mod_security support ?


Gwenn Etourneau
 

Well the impact of the WAF itself is minimal, due to LUA / Nginx
(OpenResty).
To be honest is still a POC but it's quite promising as now we don't have
to care about runtime / docker things.

On Wed, Jul 13, 2016 at 1:27 AM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Gwenn for sharing this work.

On the long term, a route service is much more flexible in that it
supports all buildpacks.

Were you able to measure the latency impact of going through a fully
brokered service WAF (w.r.t. to embedding a WAF into the phpbuildpack http
server) ?

Shannon was mentionning work related to measuring performance of fully
brokered service in the routing team, but was not able to specifically
find it in the backlog, only found a generic http routing blog story [1]
that I hope would include fully brokered service

Thanks in advance,

Guillaume.

[1] https://www.pivotaltracker.com/story/show/118804537



Guillaume.

On Fri, Jun 17, 2016 at 7:50 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Hi Guillaume,

I made a POC using route-service if you are interested
https://github.com/shinji62/waf-cloudfoundry-route-service

On Mon, Jun 6, 2016 at 4:17 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi Gwenn,

Thanks for your interest in this work. We're targeting apache support
first. If there is interest in nginx support, then we can share efforts for
such support. In the long term, a route services integration will probably
make sense, especially when direct routing to containers will lower the
latency impact.

Regarding rules updates, we're leveraging the default OWASP rules
<https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project>
(from
https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/master/base_rules)
it's likely that we'll cascade upstream changes into our fork, and automate
this in our ci work.

Regards,

Guillaume.





Guillaume.

On Fri, Jun 3, 2016 at 3:04 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Guillaume,

Are you planning to support for nginx and apache ?
How are you going to maintain the rules ?


Thanks

On Fri, Jun 3, 2016 at 12:20 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I'm still interested in hearing feedback on this proposal. Up to now,
Dan Rosen suggested into [2] that Orange maintains a fork of php buildpack
and submits it to as an incubator project.

We're starting on this topic with trying to replicate the buildpacks
ci in our infrastructure. It's likely that the buildpack-ci [3] would have
to be slightly modified to support more parametrization (e.g. to run
against different github repo urls). I'd be interested if anyone in the
community managed to run its own buildpacks ci instance, and share
experiences there.

Thanks,

Guillaume.

[2] https://github.com/cloudfoundry/php-buildpack/issues/144
[3] https://github.com/cloudfoundry/buildpacks-ci


Guillaume.

On Mon, May 2, 2016 at 5:05 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

Mod_security [1] is a flexible opensource web application firewall,
which runs configureable rules to detect and possible filter malicious
incoming HTTP requests received (XSS, SQL injection ....). Orange is
preparing a PR to add support for mod_security in the php_buildpack [2].

I'd be interested to hear if there is interest for such support in
the community and specific requirements/refinements over Orange's initial
work to be done.

Thanks in advance,

Guillaume.

ps: A possible future integration could also be packaged as a
fully-brokered route service in the future, which could be applying to all
buildpacks. As a 1st step, we focussed our effort to httpd within php
buildpack, mainly to avoid the added network hops implied by the
fully-brokered service

[1] https://www.modsecurity.org
[2] https://github.com/cloudfoundry/php-buildpack/issues/144


Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.