Skip to content
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

Open
GithubCopilotX opened this issue Jun 30, 2023 · 9 comments
Open

response_body能否返回attack_type和risk_level信息 #158

GithubCopilotX opened this issue Jun 30, 2023 · 9 comments

Comments

@GithubCopilotX
Copy link

GithubCopilotX commented Jun 30, 2023

response_body能否返回attack_type和risk_level信息,这样api网关能够灵活的对当前t1k服务端响应的attack_type和risk_level进行判断是否需要拦截本次请求,而无需在后台固定的选择拦截等级,因为后台的拦截等级是全局的,无法为不同的域名单独设置。

@blaisewang
Copy link
Member

@zclaiqcc any idea?

@blaisewang
Copy link
Member

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.

@zclaiqcc
Copy link
Collaborator

zclaiqcc commented Jul 3, 2023

1.10.0 版本之后支持对站点进行单独的「观察」模式配置。如果是不同站点希望开启不同等级的防护策略模块,暂时不支持,可以通过部署多套社区版 WAF 来解决。每个站点配置一个防护策略,无论是从交互还是检测流程上都过于复杂了,不太适合社区版的大多数用户场景,暂时未考虑支持。师傅可以去 issue 下点赞,需求量大会考虑增加 #83

@GithubCopilotX
Copy link
Author

1.10.0 版本之后支持对站点进行单独的「观察」模式配置。如果是不同站点希望开启不同等级的防护策略模块,暂时不支持,可以通过部署多套社区版 WAF 来解决。每个站点配置一个防护策略,无论是从交互还是检测流程上都过于复杂了,不太适合社区版的大多数用户场景,暂时未考虑支持。师傅可以去 issue 下点赞,需求量大会考虑增加 chaitin/safeline#83

api网关内通常不同的路由或域名有不同的业务逻辑,如果部署多套safeline是很难兼顾api网关场景,毕竟api网关请求量大,不同路由的防护等级不同,ce版本支持t1k协议接入是很关键的进步,能够敲开k8s和api网关的大门,但是能灵活配置或者引入#83 的功能,那ce版本就能完全覆盖k8s和api网关入口,那么再也没有比safeline更好的k8s和api网关的waf防护和检测方案了。

@zclaiqcc
Copy link
Collaborator

zclaiqcc commented Jul 3, 2023

还是稍微质疑一下需求场景,真的会有“一个站点一套防护策略配置”的需求么?求结合现状的防护策略模块和师傅的使用姿势,举几个例子看看?比如哪些模块在哪些站点下希望关闭,在哪些模块下希望开启,以及这种对“灵活性”的追求,是否真的达到了需要每个站点配置一套防护策略的地步。 THX

能理解“更灵活更好”,但是怀疑实际场景下是否真的有必要灵活到一个站点对应一个防护策略模块

@GithubCopilotX
Copy link
Author

还是稍微质疑一下需求场景,真的会有“一个站点一套防护策略配置”的需求么?求结合现状的防护策略模块和师傅的使用姿势,举几个例子看看?比如哪些模块在哪些站点下希望关闭,在哪些模块下希望开启,以及这种对“灵活性”的追求,是否真的达到了需要每个站点配置一套防护策略的地步。 THX

能理解“更灵活更好”,但是怀疑实际场景下是否真的有必要灵活到一个站点对应一个防护策略模块

比如api网关场景下,某域名或路由发现某检测模块出现误报,但是别的域名或路由是没有出现误报,如果按照目前的场景只能对特定域名改成观察模式或者在全局修改防护策略,但是这个修改会导致要么全局都被修改,要么特定的站点失去防护,api网关中的api有不同的用途和请求方式,所以全局的模式会导致所有api都变成一套防护策略,例如api-1中出现sql注入的误报或者需要降低防护模块的防护强度,但是api-2是需要更高强度的防护,在这种场景中就变得矛盾。

@blaisewang
Copy link
Member

blaisewang commented Jul 14, 2023

continue this thread in chaitin/safeline repo

@nntp4
Copy link

nntp4 commented Aug 1, 2023

场景:
将safeline-detector作为自研WAF的检测模块( via unix socket),且safeline- detector默认开启所有检测。希望能获取请求检测结果,例如攻击类型,然后在自研WAF模块记录相应的日志,不走safeline-mario->postgreSQL (日志量很大每天有2TB) postgreSQL 压力太大。
此场景可类推到所有嵌入式接入方案的日志记录需求
@zclaiqcc

@zclaiqcc
Copy link
Collaborator

场景: 将safeline-detector作为自研WAF的检测模块( via unix socket),且safeline- detector默认开启所有检测。希望能获取请求检测结果,例如攻击类型,然后在自研WAF模块记录相应的日志,不走safeline-mario->postgreSQL (日志量很大每天有2TB) postgreSQL 压力太大。 此场景可类推到所有嵌入式接入方案的日志记录需求 @zclaiqcc

@nntp4 这种场景肯定是购买企业版了吧,期待社区版做到这种程度感觉有点难,社区版的目标不是替代企业版哈哈哈。同时提醒一下,针对社区版的自研是违反 LICENSE 的

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants