New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
response_body能否返回attack_type和risk_level信息 #158
Comments
@zclaiqcc any idea? |
t1k protocol itself won't be changed for now, as we need to be consistent with the Nginx C t1k module. the only possible solution is to let safeline-ce's developers implement this functionality (different websites with different profiles) on their side. |
1.10.0 版本之后支持对站点进行单独的「观察」模式配置。如果是不同站点希望开启不同等级的防护策略模块,暂时不支持,可以通过部署多套社区版 WAF 来解决。每个站点配置一个防护策略,无论是从交互还是检测流程上都过于复杂了,不太适合社区版的大多数用户场景,暂时未考虑支持。师傅可以去 issue 下点赞,需求量大会考虑增加 #83 |
api网关内通常不同的路由或域名有不同的业务逻辑,如果部署多套safeline是很难兼顾api网关场景,毕竟api网关请求量大,不同路由的防护等级不同,ce版本支持t1k协议接入是很关键的进步,能够敲开k8s和api网关的大门,但是能灵活配置或者引入#83 的功能,那ce版本就能完全覆盖k8s和api网关入口,那么再也没有比safeline更好的k8s和api网关的waf防护和检测方案了。 |
还是稍微质疑一下需求场景,真的会有“一个站点一套防护策略配置”的需求么?求结合现状的防护策略模块和师傅的使用姿势,举几个例子看看?比如哪些模块在哪些站点下希望关闭,在哪些模块下希望开启,以及这种对“灵活性”的追求,是否真的达到了需要每个站点配置一套防护策略的地步。 THX 能理解“更灵活更好”,但是怀疑实际场景下是否真的有必要灵活到一个站点对应一个防护策略模块 |
比如api网关场景下,某域名或路由发现某检测模块出现误报,但是别的域名或路由是没有出现误报,如果按照目前的场景只能对特定域名改成观察模式或者在全局修改防护策略,但是这个修改会导致要么全局都被修改,要么特定的站点失去防护,api网关中的api有不同的用途和请求方式,所以全局的模式会导致所有api都变成一套防护策略,例如api-1中出现sql注入的误报或者需要降低防护模块的防护强度,但是api-2是需要更高强度的防护,在这种场景中就变得矛盾。 |
continue this thread in chaitin/safeline repo |
场景: |
response_body能否返回attack_type和risk_level信息,这样api网关能够灵活的对当前t1k服务端响应的attack_type和risk_level进行判断是否需要拦截本次请求,而无需在后台固定的选择拦截等级,因为后台的拦截等级是全局的,无法为不同的域名单独设置。
The text was updated successfully, but these errors were encountered: