本帖最后由 85039王毅波 于 2025-1-7 18:12 编辑
网络拓扑示意图
一、问题现象:服务器持续发送reset包导致AF卡顿/异常
1、11-02 AF设备上收到大量rst 219.247.255.129.XX -> 64.62.197.114.33573 [ip.id == 0x3d58递增] 报文,大量小包导致设备单核打满
2、12-07 AF设备上收到大量rst 219.247.255.20.XX -> 74.82.47.45.52567 [ip.id == 0x5826] 报文,大量小包导致单核打满,业务卡慢
二、排查过程:
1、0x5826是AC的rstid,AC为旁路部署,大量报文到AC后会发起rst报文,从AC eth0内网口发往内网核心,经过AF后导致单核打满。
2、11-02出现的rst报文中,非AC发起,目前怀疑219.247.255.129服务TCP状态已关闭,且收到大量SYN报文,导致不断发送SYN包。
3、使用EDR以及自研工具MMH对主机进行查杀未发现存在恶意进程,查看主机网络信息,未发现主机存在异常外联现象,主要是以java和docker-proxy代理为主。 4、分析态势感知和第三方设备(网盾),发现是外部主机对内网多台主机进行访问现象,根据威胁情报,发现47.82.47.45为恶意的扫描ip。总结:外部扫描导致相关主机存在异常发送rst数据包 5、在客户授权情况下,模拟黑客对内网的教育网业务进行端口扫描,复现现象并在友商AF、运维区AF等设备进行抓包,发现还是存在服务器rst回包。 6、梳理完客户真实业务拓扑和每个设备的机制,最终定位出来2个问题: a、K01设备将黑客地址加了黑名单,并且如果发现扫描或者其他攻击行为就会模拟业务系统来给发rst的包,ip.id ==
0x0000的数据包就是K01模拟业务系统发送的。 b、取消AC的默认路由,旁路部署模式不发送rst报文。
三、结论: 1、目前根据流量来看,基本是美国的扫描,而且我们也根据客户环境做了多个实验。扫描ip相关的页面,也说明自己是美国shadowserver基金会,展开的全网扫描。 2、总结:服务器之所以一直发送rst包,是因为外界恶意ip74.82.47.45,持续对用户的219.247.255.129展开端口扫描,导致该现象。 3、客户的这个教育网地址本质上还是个公网地址,虽然没有在公网开放业务,但是攻击者在扫描客户相关网段的时候,客户这个ip地址还是能够接收到相关的数据包,那么这个端口没有开放,那么服务器就会返回一个rst的数据包,表示我这个端口没有开放,这个也是nmap、masscan这类端口扫描工具的扫描原理,来判断端口是否开放。 如下图所示,我用自己本身电脑的虚拟机扫描219.247.255.129,发现服务器本身还是能够接收到我发过去的tcp数据包的。
四、解决方案: 1、出口防火墙禁止互联网方向访问内网的对应教育网IP业务---这个最重要 2、取消AC的默认路由,旁路部署模式不发送rst报文。 3、K01设备接到核心交换机。跳过运维区AF也可以一定程度规避类似问题
PS:本次属于单次应急支撑,客户对自身网络拓扑和测试设备情况不熟悉,设备主要原理和机制不清楚,对外同时涉及2个友商的设备和业务部门协调,内部涉及AC和AF、安服三方的协同排查。
|