系统入侵反追踪的排查分析

起因

        去年在广州开发了一套系统，今年在3月份有人告诉我说系统可能被入侵了，数据被盗了。我说不可能哇，这点自信我还是有的。因为自己开发的系统里面的每一行代码我都是亲自看过的。但是既然有反馈我们就要去看。后来我真发现有人入侵，真是啪啪的响呀。

分析过程

        其实我个人对安全领域懂得都是皮毛，但是好在分析入侵比攻击会简单点。凭着我的五毛钱的功底以及福尔摩斯般缜密的思维，还真被我发现了痕迹。这里要说一下发现痕迹千万急着清理入侵文件，保留好，因为知道入侵了但是我们还要学习下人家的入侵手段，方便以后更好的防御嘛。接下来我们说说我发现入侵痕迹的过程

服务器日志

        在服务器初始化的时候一定要最好基本的运维工作，例如nginx的日志和日志格式，数据库服务必须配置好远程访问白名单，程序运行用户。我们幸运的是web服务器 nginx 的日志配置非常详细，并且程序运行用户只能看日志是无法删除的。看日志是一个很枯燥的事情，从大量的请求日志中分析出来异常的请求。直到下面一件事情才让我从枯燥的查日志的事情中解放

Git版本管理

        我们所有项目的发布都是通过发布平台发布，而所有的代码又是通过git服务实现管理。这一刻我觉得git真的太可爱了。我通过执行 git status下面看到有未提交的文件，这一刻就很明确了，最终的元凶就是 ueditor。因为在ueditor 目录里面新增了 action_oss.php 文件。那么这个文件是如何上传进来的？如下图 

具体代码传送门：点击这里

这一刻就知道了，原来是这里惹的祸。但是在我印象中这个地方是没有入口的，因为ueditor不用的文件我都删除了。后面找广州团队回顾 这是一个小兄弟做某个项目带上去的。这一刻才真真让我们把安全意识以后要融入业务培训中，当前已经是数据时代，数据才是最值钱的。所以保护好数据是非常必要的。

入侵文件分析

        action_oss.php这个被上传上来的文件是一个图片 + php代码的文件。这个文件被上传到web入口目录了，所以入侵的人就可以直接输入对应的网址进行访问了。如下截图可以看得更清楚。

根据上面的截图大家其实可以看出里面有一段php的代码可以执行传过来的参数。经过我们分析之后可以得出参数转化之后就是原始的各种SQL语句。

反追踪

        上面能够分析出来传递过来的信息也是因为我们进行了反追踪，我们在被入侵的文件中进行了日志记录，将请求的参数都记录下来了，进行分析得出了意图。广州那边由于损失了数据就进行了报警，然后我们就手机用户的入侵记录进行配合。所以奉劝大家随着国家越来越重视数据安全，千万不要做买卖数据的事情。

下面就是我们记录的入侵参数，可以获取到攻击意图。然后结合内部和外部系统可以为推断提供决策

蜜罐

        由于我们既为了协助破案，又不能数据被偷走，所以我们部署了蜜罐，其实这东西我也不太懂，但是我就是根据我自己的经验对入侵的特征进行了分析，然后这样入侵的人以为还在访问原系统，其实访问的是我们专门部署好的假的系统，每天我们补充数据就行了，

解决方案

        很多人想到的就是删除入侵文件和入侵点就好了，但是我后来思考了下，最稳妥的办法就是让你以后就算找到了入侵点，进来了你也执行不了：就是请求任何php文件 ，如果不是index.php 一律重定向到 index.php，所以我改了nginx的配置文件。如下图