记一次webshell排查但又无webshell的应急

某次应急中，客户吓坏了，说是内网流量分析设备中有很多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连接告警，实际上，服务器并没有沦陷，只是攻击者在外网的扫描行为触发。

后话

回头看，原来就这么一回事，但是实际上，在客户现场折腾了一