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

起因

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

分析过程

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

服务器日志

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

Git版本管理

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

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


600

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

入侵文件分析

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



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

反追踪

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


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


蜜罐

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

解决方案

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