某次应急中,客户吓坏了,说是内网流量分析设备中有很多webshell连接告警,作为一名卑微但又不失理想的安服仔,毅然直奔前线…
过程
去到现场后,直接打开客户的流量分析设备,的确看到一堆冒红的webshell连接告警,看到来源ip有公网的,直接先排查公网对内部系统的攻击,但是排查后,发现目标攻击的系统并没有被入侵,但为什么内部系统会有大量的内网对内网webshell连接尝试何失败日志?如下图所示:
于是申请到15.1的主机上进行排查分析,登陆到192.168.15.1服务器上进行排查,发现无异常外联
也没有异常的进程,查看最近登陆的日期,发现并无任何异常。
最后排查到该主机具备公网域名,并且有做nginx配置,查看nginx配置存在include *.conf ,所以对/usr/local/nginx/conf.d/目录下进行排查
所以对/usr/local/nginx/conf.d/目录下进行排查,最后终于发现了问题,app.conf文件配置了内网15.8 ,15.9 ,15.10的分发,
查看nginx的access.log日志,发现外网攻击者扫描过这个nginx,以及许多扫描的webshell名字路径。
所以基本可以确定,因为测试区的nginx能被互联网访问,所以攻击者扫描外网时,nginx把扫描的路径分发到内网的几台服务器中,并且流量设备只是简单的对文件名进行了常见webshell名字匹配,匹配成功则出现告警,没有判断响应包的状态码是否正常,所以产生了很多内网对内网ip的webshell连接告警,实际上,服务器并没有沦陷,只是攻击者在外网的扫描行为触发。
后话
回头看,原来就这么一回事,但是实际上,在客户现场折腾了一