机房计算节点登录服务器发现大量来自企业VPN隧道内的攻击,看IP地址段是来自IPSECVPN的。怀疑又是哪个用户的终端机中毒了,结果拿着IP到VPN服务器上去查询XAUTH认证,居然没有和这个IP对应的账号登录信息!但是防火墙会话表中又确实能看到这个IP和服务器的会话记录,源安全域也是来自VPNHUB,并非内网其它机器伪造源IP,这就很奇怪了。冥思苦想也只能往伪造IP地址上去靠,但是VPN客户端需要认证才能分配到IP,理论上是没法伪造IP和绕过认证记录的,这个VPN隧道内的虚拟IP到底是怎么获取到的搞得我很头疼。
从攻击的目的IP来看,都是同一个用户租用的独立服务器,根据这个用户之前出过的一系列问题,基本上还是锁定问题出在这个用户的终端上。与用户系统工程师沟通,果然发现对方的服务器配置有问题。
这个用户其实相当于我们的一个代理商,他们终端通过vpnc客户端登录IPSECVPN访问我们数据中心的资源。
然后又在这台服务器上做了dnat,将VPN隧道内的资源以公网IP+端口的形式给他的子用户访问,同时通过snat转换成VPN隧道的虚拟IP地址来访问资源。问题就出在转snat这一步,代理商以为每次登陆IPSECVPN分配到虚拟IP不变,所以在snat中使用了静态的ip地址,而IPSECVPN隧道的生存时间最高为24小时,也就是其实每天都在重新连接重新分配虚拟ip。但是因为snat配置静态ip地址,实际转发过来的源地址又与分配的虚拟ip不同,所以导致在VPN服务器这边看到的XUATH认证记录与实际会话的源ip没有关联。
也就是VPN服务器网关往客户端虚拟IP转发的时候并没有去关联XUATH认证分配的IP地址,这么狗血的bug还真是头一回碰到,现在也无法确认是ipsecvpn本身没考虑这个问题,又或者是VPN服务器厂商的锅?
幸运的是,这次产生的攻击并非真实攻击者,代理商的服务器是租用在阿里云的,同时也启用了阿里云盾的漏扫和弱口令检测,通过VPN隧道跑进来的这些扫描和攻击都是来自阿里云盾的检测。
总之已经将bug反馈给厂商了,等待他们先搭建实验环境复现这种情况吧~至于是否能修复,按厂商一贯表现,估计又是一次漫长的等待。还好在防火墙上对snat后的源ip做安全策略能起到阻断攻击的效果,在防火墙阻断假ip的时候客户端那边也会出现访问受限的现象,如果是客户端的无心之举倒也能通过这种方式排查。如果是心怀不轨利用这个漏洞攻击,那就很恶心了,无法确认ip和用户账号的关联,根本找不到事主。
后记补充:我傻了,突然才反应过来,原来可以在安全策略中配置源ip的账户匹配~进入隧道的流量经过VPN的封装后,抵达防火墙,防火墙对流量解封装,得到明文流量。VPN仅仅只是对数据包加解封装,然后流量的筛选和转发依然是由policy和route来做,明文中是包含用户信息的~~~
问题顺利解决,撒花完结~~