12 KiB
福建项目：功能端命中安全策略但未发rst
| ID | Creation Date | Assignee | Status |
|---|---|---|---|
| OMPUB-824 | 2023-02-28T14:53:49.000+0800 | 刘学利 | 已解决 |
测试网站：https://kf.xn--fiq01iq2nuta337et7ov3wo3y.com 命中策略ID：134 命中object item：*xn--fiq01iq2nuta337et7ov3wo3y.com
问题描述：功能端在tcpdump_meas捕包可以看到访问的流量，同时在管理口捕包没有对应的rst。界面可以看到相应的安全策略日志
说明：该网站有http和https，http命中135策略，正常发rst。https命中134策略，未捕获rst
!image-2023-02-28-14-57-36-655.png|thumbnail! !image-2023-02-28-14-57-47-786.png|thumbnail! zhangzhihan commented on 2023-03-31T21:52:22.351+0800:
2023.03.31在福州移动4G复测，当流量经过福州移动一厂机房时，穿透较为严重。测试访问自建http网站 http://36.255.221.179 ，策略为IP阻断策略，发现sapp会出现不发rst的情况，例如第一次访问，出现了阻断，但刷新后出现穿透，通过抓tsg-os的日志口包发现，穿透的时候sapp没有发rst，并且穿透的时候界面没有命中日志。 测试流量固定经过192.168.16.12服务器，尝试将16.12的sapp目录备份，并替换为另一台福州移动4G服务器的sapp目录（该服务器测试正常），替换后测试现象仍为sapp未发rst包
liuxueli commented on 2023-04-01T15:10:21.909+0800:
- 访问36.255.221.179阿里云自建服务，策略条件为服务端IP(36.255.221.179)，tcp 端口重用导致阻断的效果不佳。
liuxueli commented on 2023-04-01T16:26:54.195+0800:
- 测试同时在客户端、功能端、服务端捕包，本次测试客户端均未收到RST包。 ** 客户端捕包：[^1-client-36.255.221.179.pcap] ** {^}服务端捕包：{^}[^1-server-36.255.221.179.pcap] ** {^}功能端捕包：{^}[^1-tsg-36.255.221.179.pcap]
- ^3个捕包点捕获的数据包中的连接数一致，共8个链接，使用clientPort、Server IP、clientISN条件在安全事件日志中均找到对应的事件日志。^ ** client_port=58408 serverIP=36.255.221.179 clientISN=109015579 client_port=58410 serverIP=36.255.221.179 clientISN=904314205 client_port=58409 serverIP=36.255.221.179 clientISN=1353384079 client_port=58417 serverIP=36.255.221.179 clientISN=2535026249 client_port=58418 serverIP=36.255.221.179 clientISN=1380987268 client_port=58419 serverIP=36.255.221.179 clientISN=2847006069 client_port=58423 serverIP=36.255.221.179 clientISN=3068429057 client_port=58427 serverIP=36.255.221.179 clientISN=3217186535
yangwei commented on 2023-04-01T17:20:11.384+0800:
现象
- 附件[^36.255.221.179.ct.port-reused.pcap]中的两个TCP会话（源端口分别为61843和61844），都出现了SYN重传（SYN retransmission）的现象，而非TCP端口复用（TCP port reuse）
- 端口复用的前提是前一个会话结束，并且使用相同的四元组重新协商初始化序列号ISN（Initiate Sequence Number），而pcap包中的会话并没有显式的结束，Client侧的行为是在500+ms的间隔内连续发送了两个ISN相同，但是IPID不同的SYN包，属于SYN重传
分析
- 对于sapp的处理逻辑，syn重传对于发送rst干扰TCP会话原则上并没有影响
- 只要根据第一个syn触发的rst及时到达Client和Server，而Client和Server正常响应，目标会话就会结束
- 在正确性假设成立的情况下，就算重传了第二个syn，sapp认为是重传，而没有补发干扰包，也不影响第一个rst的效果
验证
PS：值得注意的是，pcap包中的Client IP为192.168.43.84，在京版服务器上进行读包测试时，可能会因为和京版地址段重合（192.168.40.0/21），导致在测试机的管理口上捕不到sapp发给S2C侧的rst包
liuxueli commented on 2023-04-01T17:34:55.276+0800:
- 测试同时在客户端、功能端、服务端捕包，第二次测试存在三种现象： ** 客户端正常收到RST包，链接被正常阻断 ** 客户端正常收到RST包，链接未被正常阻断 *** 客户端收到RST包后，链接上出现短时间范围内重传SYN包重传的现象 ** 客户端未收到RST包，链接正常访问 *** 根据client_port=58860 serverIP=36.255.221.179 clientISN=962091815条件查询，安全事件日志中有记录，说明本链接命中了安全策略。 **** !client_port=58860 serverIP=36.255.221.179 clientISN=962091815.jpg|thumbnail! *** sysinfo.log中观察到功能端发送RST较多，可达到1.9万/秒 **** !image-2023-04-02-18-08-57-198.png! ** 参见： *** 客户端捕包：[^2-client-35.255.221.179.pcap] *** {^}功能端捕包：{^}[^2-tsg-36.255.221.179.pcap] *** {^}服务端捕包：{^}[^2-server-36.255.221.179.pcap]
yangwei commented on 2023-04-02T13:43:18.362+0800:
根据上述描述的现象和相关数据包，小结如下，有不准确之处，[~liuxueli] 和 [~zhangzhihan] 补充修正：
-
测试过程
** 福建移动网的部分运营商（特定一家？），存在干扰效果不佳的情况（俗称穿透），{}对应智涵在Description中描述的部分{} ** 为验证该现象的普遍性，智涵在阿里云自建了一个网站，方便结合拨测客户端，进行自测 ** 第一波测试结果显示对于自建网站，仍然存在穿透，{}对应智涵的第一条评论，{}在拨测客户端捕包[^36.255.221.179.ct.port-reused.pcap] *** 为简化条件，将自测的安全策略设置为服务端IP，仍然效果不佳 *** 为了排除部署的原因，将其他没有穿透现象的功能端目录拷贝至该站点，仍然效果不佳 *** PS：上述两个方法基本可以排除穿透原因，是由于服务端的特殊性，或者部署参数不一致导致。 ** 学利分析了捕获的数据包，得到“tcp 端口重用导致阻断的效果不佳”的结论，{}对应学利的第一条评论{} ** 学利也使用自测条件，进行了一轮复测，分别对客户端，服务端，和功能端接收到的镜像流量，进行了捕包并附在评论中，这一轮测试的结果是功能端“本次测试未发送RST包”，{}对应学利的第二条评论{} ** 经过与学利的交流，学利进行了他操作的第二轮复测，同样在相同的位置进行了捕包并附在评论中，这一轮测试加上了对安全事件日志的查询，得出的结果是“安全事件日志中有记录，说明本链接命中了安全策略”，{}对应学利的第三条评论{}{}{{}}
- 问题分析 ** 上述测试过程，暂时可以得出以下结论 *** 穿透发生的范围，限于部分运营商的移动站点，而非所有站点 *** 穿透的对象，与策略条件无关（SNI或者IP都穿），与服务端的特殊性也无关（自建网站可以复现） ** 穿透可能性分析 *** 镜像模式下，TSG穿透的现象按是否存在安全日志，和在客户端服务端是否收到RST包，可以分类为： **** 有日志，有RST->效果不佳 ***** 可以排除策略条件和功能端策略执行的问题 ***** 原因可能为功能端包处理延迟大，或者干扰链路延迟 **** 有日志，无RST->无干扰效果 ***** 可以排除策略条件和功能端策略执行的问题 ***** 原因可能为干扰包封装问题（如包含MPLS或者VLAN），通常在固网环境不存在，{}移网环境后文进一步展开说明{} **** 无日志，无RST->无干扰效果 ***** 日志不缺失的前提下，属于安全策略未命中，需要检查策略条件和功能端解析和执行策略的逻辑 **** 无日志，有RST->见鬼了 ** 移网环境干扰包原理 *** 发送流程和观察点捕包方法见下图 *** 由于增加了PacketAdapter对干扰包进行修改的流程，加长了干扰包的处理路径 *** 目前图中①和②的数据包暂时没有提供观察手段，因此仅在观察点D捕包未发现RST，不能完全定位功能端的故障点
!移动网观察点-移动网观察点.drawio.png|width=721,height=593!
- 小结 ** 根据前述现象和附的相关数据包，目前福建穿透现象的可能性如下 *** 现象1：有日志，有RST->效果不佳，对应智涵在description中的描述和附上的数据包 **** 可能原因：功能端本身包处理延迟大，或者转发干扰包的链路存在较大转发延迟 *** 现象2：有日志，无RST->无干扰效果，对应学利进行的两次拨测 **** 可能原因： ***** sapp发送干扰包问题（如封装包含MPLS或者VLAN），已通过对比镜像流量和sapp日志排除，未出现sapp相关发送报错的日志 ***** PacketAdapter处丢包，观察自测流量经过的功能端，发送RST包的pps已经达到1.9w/s，不确定是否会对PacketAdapter产生性能影响，需要进行压力测试排除该原因 ** 下一步将先对这些可能性进行排查和排除
zhangzhihan commented on 2023-04-02T16:33:26.138+0800:
根据[~yangwei]描述的【现象2：有日志，无RST】的原因，查看Prometheus发现，测试功能端（16.12、13）发送rst峰值量已经达到了4.5w条/s !screenshot-1.png|thumbnail!
观察Nezha上的Sapp_Send_RST蜂窝图发现，该局点（福州移动-一厂），不管是4G还是固网，RST的量都是其他局点的几倍 !screenshot-2.png|thumbnail!
yangwei commented on 2023-04-02T17:12:47.836+0800:
帮忙确认一下：
- 本issue描述的现象，主要集中在福州移动一厂的4G站点？还是同样有其他运营商的4G站点？
- 福州移动一厂的固网站点（RST包量同样较高），是否也存在本issue描述的现象
建议确认下福州移动一厂RST包高的原因，是否由于部分安全策略命中率过高导致，或者是因为这个站点的流量显著高于其他站点
zhangzhihan commented on 2023-04-03T09:55:32.374+0800:
[~yangwei] 1、本issue描述的现象，只要集中在福州移动一厂4G站点； 2、周日粗略测试福州移动一厂固网，发现也有未发rst的问题（可能，因为在客户端和服务端都没看到rst，但是运营商固网的分流不是很固定，有时候会飘到其他站点的功能端），一厂固网的功能端发送RST的量也很大，都在4w/s以上，甚至6-8w/s； 3、福州移动4G有两个站点：一厂、马尾。通过device_group对比一厂4G 和 马尾4G 1小时、24小时deny的日志量，两者日志量相当，但是一厂4G的RST量是马尾4G的量的好几倍
yangwei commented on 2023-04-03T10:36:53.948+0800:
[~zhangzhihan] rst包pps 6-8w/s的情况下，运营商提供的干扰链路也不能保证不丢包，这个需要在功能端管理口（观察点D）和客户端（观察点A）or服务端（观察点B）对比，确认干扰链路转发无误
zhangzhihan commented on 2023-04-04T09:29:52.918+0800:
[~yangwei] 福州移动一厂4G目前已关闭封堵补救，单台rst数量从平均1.5w/s下降到了1200/s，目前测试效果恢复正常。关闭封堵补救之前观察packetadapter的cpu占用，单核us占用35%，sys占用60%，cpu已经爆满。
Attachments
36784/1-client-36.255.221.179.pcap
36785/1-server-36.255.221.179.pcap
36786/1-tsg-36.255.221.179.pcap
36787/2-client-35.255.221.179.pcap
36788/2-server-36.255.221.179.pcap
36789/2-tsg-36.255.221.179.pcap
36783/36.255.221.179.ct.port-reused.pcap
36790/client_port=58860+serverIP=36.255.221.179+clientISN=962091815.jpg
35597/image-2023-02-28-14-57-36-655.png
35596/image-2023-02-28-14-57-47-786.png
36794/image-2023-04-02-18-08-57-198.png
36792/screenshot-1.png
36793/screenshot-2.png
36791/移动网观察点-移动网观察点.drawio.png