卡巴斯基拦截TCP端口扫描事件 溯源与后续安全处置咨询

原始告警详情 #

User: NT AUTHORITY\SYSTEM
User type: System user
Component: Network Attack Blocker
Result description: Blocked
Name: Scan.Generic.PortScan.TCP
Object: TCP from 104.152.52.xxx at 192.168.0.10:1701
Additional: 192.168.0.10
Databases release date: Yesterday, 1/19/2022 12:34:00 PM

已知前置信息 #

• 告警涉及的192.168.0.10是运行Debian系统的虚拟机，已部署UFW防火墙，1701端口未配置放行规则，默认处于拦截状态
• 已在Debian虚拟机执行sudo netstat -tulpn | grep 1701排查端口监听状态，未查询到1701端口对应的监听进程

问题解答 #

（1）本次端口扫描是否覆盖了我内网环境下的所有设备？ #

从现有信息判断，没有证据支撑本次扫描覆盖了内网所有设备。
卡巴斯基本次仅拦截到发往192.168.0.10:1701的单个TCP探测包，这类探测绝大多数是公网僵尸网络的随机批量扫描——1701是L2TP VPN的默认服务端口，互联网上每天都有大量扫描器随机扫公网IP段的这个端口，尝试碰弱口令或者未打补丁的VPN设备，不是针对你内网的定向遍历扫描。
正常情况下公网扫描源无法直接触达你内网未做端口映射的其他设备，如果真的是全内网段扫描，你内网其他开了安全防护、开启防火墙日志的设备应该会同步出现同类告警，目前没有这类交叉验证的证据。如果后续你内网多台设备陆续收到同来源的扫描告警，才需要考虑内网存在跳板、边界被穿透的可能。

（2）可通过哪些方法溯源本次端口扫描的真实来源？ #

可以按从易到难的顺序操作：

• 首先查边界网关（路由器/光猫）的会话日志，定位104.152.52.xxx的流量走向：确认是公网直接发向192.168.0.10:1701的入站流量，还是内网某台设备主动外联这个公网IP后产生的回包，先排除内网失陷主机被当作扫描跳板的情况
• 查Debian虚拟机的UFW日志，默认日志路径为/var/log/ufw.log，执行sudo grep 104.152.52.xxx /var/log/ufw.log拉取该IP的所有拦截记录，看这个IP除了1701之外有没有探测其他端口、探测频率是多少，区分是随机扫还是定向探测
• 如果需要进一步确认扫描特征，可以在网关或者Debian虚拟机上用tcpdump抓包，执行tcpdump host 104.152.52.xxx抓取所有和该IP相关的流量，看数据包是Masscan、Zmap这类通用扫描器的无Payload SYN包，还是带特定漏洞利用特征的探测包
• 注意：如果确认是公网直接发起的入站扫描，不需要深挖IP背后的实际操控者，这类公网扫描IP绝大多数是被攻陷的云主机、家庭宽带设备，攻击者基本都会挂多层代理，普通用户没有溯源到具体个人的条件和必要。

（3）本次端口扫描事件会造成哪些安全影响？后续需要采取哪些应对处置措施？ #

安全影响

本次事件没有实质安全风险：卡巴斯基已经自动拦截了扫描流量，同时Debian虚拟机的UFW默认拦截1701端口、且该端口没有任何服务在监听，相当于扫描包打到了一堵没有门的墙上，完全没有可被利用的入侵入口，不存在被攻破的可能。
唯一需要留意的异常信号是：如果后续这个IP或者同IP段持续对你内网多个端口、多台设备发起高频探测，说明你可能被定向盯上，需要提升防护等级。

后续处置措施

• 不需要针对本次单条告警做特殊应急响应，接入公网的设备每天被各类僵尸网络扫几十上百个端口是常态，只要终端防护、边界防火墙正常拦截就不会出问题
• 检查边界路由器/光猫的端口映射配置，确认1701端口没有被意外映射到公网，如果平时不用L2TP VPN服务，直接删除所有相关的端口映射规则
• 保持Debian虚拟机的系统补丁定期更新，UFW维持默认拒绝入站连接的规则，非必要不对外开放端口
• 可以在网关层配置简单的扫描防护规则，比如1分钟内同一个IP发起超过10次针对不同端口的SYN请求就自动拉黑该IP，减少后续无效扫描告警的干扰
• 后续如果出现同一源IP持续多端口探测、或者安全软件弹出漏洞利用拦截的告警，再手动把对应IP加入黑名单即可。

内容的提问来源于stack exchange，提问作者yeahman