
Guillaume Berche
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-ciGuillaume.
toggle quoted message
Show quoted text
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
|
|
Guillaume,
Are you planning to support for nginx and apache ? How are you going to maintain the rules ?
Thanks
toggle quoted message
Show quoted text
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
|
|

Guillaume Berche
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
|
|
toggle quoted message
Show quoted text
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
|
|

Guillaume Berche
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/118804537Guillaume. 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
|
|
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.
toggle quoted message
Show quoted text
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
|
|