一个。在nginx层的公司级监控中，发送的请求超过了某个接口设置的QPS阈值
湾。在web框架的监控中，请求QPS超过阈值
C。在业务自己设置的监控中，请求超过阈值
d。业务接口本身没有超过阈值，但是后端的二次调用或者多次调用（RPC或者其他http服务）超过阈值
如何处理？
2.1.2 聚合控制qps的关键点
QPS控制需要确定两点：
1 聚合方式：如何将不同的URL聚合成一个key
为什么需要聚合？我们要控制的是对业务接口的请求量，而不是我们看到的 URL 的访问量。
a 相同的路径，但参数不同，大多数情况下处理的是相同的接口和相同的功能；
b 而且现在动态参数很常见，比如百度贴吧帖子
最后十位数字不在参数中，而是在路径中。后端将该路径的值作为变量读取。不管数字如何变化，都是由同一个接口处理的。
c 甚至子域也可能对应同一个接口
大多数情况下，不同的城市，如北京bj、上海sh、广州gz等，都对应同一个美食列表页面服务
如果未聚合，则为每个看起来完全相同的 url 设置 1 的最低 qps。同时扫描post时，即使每个url每秒只发送一个请求，但在同一时间段内url数量较多时，也会进行此处理。接口发起的流量也会变得非常大。尤其是在业务高峰期（早上8:00到晚上10:00有大量业务请求），接口压力相当大。基于流量镜像方式，接收到的URL也很多。进行另一次扫描很容易破坏业务。的悲伤。
因此，聚合理论上是在自己的范围内将具有不同表面的 URL 捆绑在一起。当然，界面越接近，越准确。
2 QPS值：对应key可以使用多少QPS，每秒可以发送多少请求
QPS 值取决于接口的容量和设置的告警阈值。
值设置高，容易炸毁服务接口；如果该值设置得低，扫描速度会变慢，并且在流量大的情况下可能消耗不完。
最合适的上限值是正常业务条件下请求量的平均值或上限。
有些服务会根据每分钟的请求总数设置告警，每分钟100-1000，对应QPS为1-17。对于流量较小的接口，QPS 为 1 就足以报警。
2.1.3 不同的实现
域名聚合
同一域名或子域名的请求不应超过 N(5-10).
一刀切的方法具有成本低、效果好等优点。
缺点是绝对相等，无论流量大小都使用相同的QPS。当流量较大时，可能无法完成扫描。
与任务绑定适用于扫描任务多但每个任务流量不大的情况，例如多用户多任务。
b 集群聚合
对于每一个url，根据nginx解析结果，获取该url最终所属的业务集群。
结合内部监控数据，获取各集群的实时访问量，计算各集群的访问峰值；
用峰值减去实时流量（前n分钟）得到备用可用流量
缺点：
1 依赖于内部基础设施的资源
2 对于同一集群下的接口，可用的访问权限是基于整个集群的。比如A可以用300、B可以用300、C可以用300，整个集群可以用900，但是A自己只能承受500。这样一来，就会有一个QPS 倾斜，所有访问都会命中 A，这会炸毁 A。
c 去重聚合
镜像模式下，基本上会有一套去重流程和流量清洗服务，去重时会记录每个key的实时访问量。
使用去重key作为聚合值，QPS计算方法和之前一样。计算每个key的峰值，然后减去前n分钟的qps（在可控范围内尽量少），得到这个可用的key在分钟内。
结合路径相似度和页面相似度的去重，去重key贴近界面，效果理想。
2.1.4 QPS 限制方法
如果插件的最小任务单元已经拆分到请求级别，则可以将请求任务放入队列，根据可用量读取并运行请求任务。
但是插件需要上下文关联的情况很多，比如第一次请求获取登录凭证token，第二次请求使用token进行后端RCE等。
此时扫描规则发送请求时，该请求没有可用的QPS，如何限制
方法一
直接休眠，等待它可用再发送，但会导致任务挂起，占用节点。有多少资源并不重要。
方法二
超过限制后返回重试队列
但下一次扫描不是从头开始，而是从上次停止的地方继续扫描
没有断点重新扫描，一些插件将无法被完全扫描。比如有些规则在扫描的时候没有限制，每秒10个请求，不能成功；并且QPS控制服务的边缘属于引擎，应该不影响规则本身的检测。影响
记录每个扫描任务的每个请求哈希（url++），对插件进行分类（有无上下文键）；
对于没有上下文的规则，直接跳过下一个任务已经请求过的hash；对于有上下文的规则，存储每个hash的返回，重试时已经请求的hash直接从前一个返回中读取。
2.2 业务错误码错误
业务线将监控服务的稳定性和可用性。最简单的是错误代码的百分比，例如每分钟 404/504。
可用性将直接影响业务 KPI 和指标。
在这里，您应该收集每一个反馈，与内部监控平台沟通讨论需求，并在识别到内部扫描时删除这部分请求；如果是单个业务自己收集错误，就只能自己解决这些问题。
这里注意保持业务溯源简单，扫描的时候自定义/ua/ IP等，否则要等很久才能追根溯源才发现是内部扫描，业务会比较多生气的。
2.3 脏数据
脏数据是一个无法避免的问题。
镜像模式下，只过滤掉post和post，只扫描get，可能还是有脏数据问题。
理论上get应该是用来查询和操作的，但是业务要做增删改操作也是可以理解的。
get里面可能有用户凭证，业务并没有把token放到里面，而是放到get参数里面，一般会保存在里面。这种情况下，用get参数值扫描就相当于用用户的身份扫描。如果有信息的增删改操作，用户的数据就会变脏。
再比如业务写接口，登录接口获取手机验证码，?phone=xxx&type=1，获取此流量进行扫描，扫描类型时，重复发送验证码给用户，用户认为该帐户正在被涂黑。
或者，没有增删改查等，只是简单的查询，却因为频繁访问用户信息，被逆转，用户被封禁。
方法 1 清洁和标记
在2.1中，我提到了接口；在我们拥有所有接口数据后，借用其他安全产品（SAST/IAST）的能力，给接口打上标签，判断是增删改查；添加、删除、修改操作只需小心跳过，避免大部分脏数据业务影响。然后设置参数名黑名单，过滤掉具有明显用户特征的参数名取值，如phone/token/tele。
这种方式比较安全，覆盖范围取决于SAST/IAST的能力，但是也会导致这些接口的漏报
方法二爬虫
通过爬虫，第一篇1.2.4，使用自己的测试账号抓到的流量，通常脏数据问题会比较少，因为这些请求是普通用户可以访问的，是从外部发送的来源。扫描仪将收集它。
用户可以访问的界面会造成脏数据，也就是说外部用户也可以造成脏数据，尤其是外部白帽/黑客也会扫描。不是不扫描就不存在问题，只是没有暴露出来。
方法三阴影环境
直接复制已有的DB环境和服务环境，将扫描请求/压测请求通过nginx层转发到影子环境。风险极低，但代价巨大（cost*2）.
或者干脆复制DB环境，在数据库连接函数中做一个hook，把扫描请求的数据库链接改成影子库。但是操作起来很麻烦，开发和维护成本高，而且多层调用最终到达DB，很难判断是否与原始请求关联扫描。
并且除了常规的数据库mysql/mongo/redis/MQ/kafka等，还有其他数据库甚至本地日志等，有的操作转了其他的操作没有转，业务数据层不一致，并且只能通过反馈来维持。，比较麻烦，不推荐。
方法四测试环境
第一篇1.2.6，扫描测试环境。
开放扫描作为业务线的一项功能。当业务可控时，无需过滤各种参数即可进行扫描。QA 在了解风险时进行扫描。
甚至可以进行流量标记，允许业务选择是否扫描涉及到增删改查的接口。
PS：
在一些收购业务中，当系统被扫除时，就会出现问题。没有统一的测试环境，也没有统一的在线获取接口标记代码的流程。它非常脆弱，未经授权的访问无处不在。在这种情况下，什么也做不了。
2.4 扫描时间段
有些业务允许扫描，但希望扫描时间在半夜，因为半夜业务流量低，出现脏数据或QPS等问题，影响比一天中的高峰时段要小，营业“开门”时也有一定程度的“开门”。缓冲时间。
2.5 限制带宽
虽然可以进行过滤，但会造成成本问题，不像静态文件会影响扫描性能。
扫描时，可能会遇到下载文件的界面。一次请求后，接口会将几十或上百兆的文件内容返回给客户端。QPS一上来，带宽就起飞了。在私有云场景中，可以通过云服务购买带宽包，可以收取分级费用，也可以收取使用费。一旦超过，可能会多花几百万，足以造成严重事故。
所以在过滤流量的时候也要过滤掉-,-type属于下载类型。
0X03 主机端口扫描无害3.1 内网HTTP服务错误
暂无评论内容