从一次应急响应看Linux文件安全

事件起因很简单,某网站页面被篡改。客户要求也很简单,删除被篡改页面。

MR06S4LBSAM7Z_X94NGM

可想而知如果能简单删除,也不会有此次应急。系统为linux,进入后查看文件权限如下:

20140805112736

带”+”号的文件,这里出现了第一个linux文件安全相关的知识点“linux文件ACL”。什么是“ACL”,可以简单理解为给特定用户或用户组设定对于一个文件/文件夹的操作权限,这个ACL包含我们平时chmod设置ls -l查看到linux文件权限。

使用getfacl可以查看一个被篡改文件,发现加入了一条特殊权限“user:root:—”,这表示root对该文件没有任何权限。直接rm是无法删除的,如下图:

25

看到这里,首先想到利用 setfacl -m u:root:rwx 将root权限设置回去,使root用户可删除篡改文件。但当setfacl -m执行后,提示没有权限修改。再次setfacl -b取消所有的acl,还是提示没有权限修改。现在用户是root,什么原因造成的没有权限?这里就有第二个和linux文件安全相关的知识“文件隐藏属 性”。

发现文件都被标识了i属性(禁止对文件进行任何修改),这也是为什么setfacl无法还原权限的原因。用chattr -i命令去掉”i”属性,没有任何返回信息,再次查看发现“i”属性仍未被去除。

这里是第三个linux文件安全的知识点“系统命令替换”,chattr没有生效,怀疑该系统命令已经被入侵者替换掉。做了个实验:使用 chattr +a给某一个页面文件设置a属性,可以正常设置,再使用chattr -a去掉属性成功。在/tmp目录新建1.txt文件,使用chattr +ais为1.txt设置多个隐藏属性,再用chattr -ais取消属性发现只有i属性无法撤销,之前的推测被证实。

还原系统命令操作起来很复杂,QQ远程协助还要过堡垒机操作太麻烦。替换不了我们找替代方案,想到android测试常用到的系统命令工具包busybox,最后busybox chattr -i解决了该问题。

PS:如果该服务器可以连网,使用

可重装chattr命令。

【via@STD兄弟连