<<返回上一层

美国服务器被黑客入侵怎么办?

发布时间:2018-08-23

禁用攻击文件

收集完所有这些信息后,不要忘记将恶意文件渲染成无用的。我已经删除了所有用户的阅读和执行权限,但在系统运行了一段时间后,我将删除它们。系统中不应该留下任何损坏的文件,以防有人不小心将它们重新激活。

建立一个攻击时间表

在前面提到的 mac-robber 工具之前,我已经检索了文件信息,我用 mactime 创建了这个信息的时间轴。

mactime -b timeline.txt 2017-06-01 > timeline_output.txt

然后,你会得到一长串类似下面的条目:

Fri Jun 30 2017 15:43:02      308 .a.. -rw-r--r-- 10000    1004     0        /var/www/vhosts/xyz/httpdocs/way.php

Fri Jun 30 2017 15:51:55      308 m.c. -rw-r--r-- 10000    1004     0        /var/www/vhosts/xyz/httpdocs/way.php

Fri Jun 30 2017 16:07:47       31 m.c. -rw-r--r-- 10000    1004     0        /var/www/vhosts/xyz/httpdocs/newmessage.html

这是美国服务器上所有文件的非常有用的列表,包括所有者 id、组 id 以及文件修改、访问和更改的时间戳。

请注意,在 Unix 上,通常会获得文件访问时间、文件更改时间和文件修改时间(atime,ctime,mtime)。

这些是在文件大小之后的 mactime 时间线文件中显示的,例如上面示例中的第二行中的 m.c.,这意味着给定的日期会显示文件修改和更改时间。

在访问文件时设置 a(atime);c(ctime)是在文件内容或权限发生更改时设置的;当文件内容发生了变化,而不是所有者或权限更改时,设置 m;在创建文件时,设置 b。

因此,mtime 在文件最后写入时向我显示。但是我不能确定它是否与文件创建日期相匹配。

不幸的是,这里无法重新构造,因此我不能确定这是上传的时间,但是我可以确定,在周五,Jul 07 文件已经在系统上了。在 Linux 上,你可以使用工具 stat 来显示单个文件的这些信息。

还有一些与文件系统,文件访问,创建时间有关的副标题。首先,如果你的文件系统安装了 noatime 选项(你可以通过运行 mount 命令来解决这个问题),则不需要编写访问时间。虽然这能增加取证速度,但显然非常复杂。

然而,好消息是,根据你的文件系统,你可能能够找到文件创建时间。Ext4 支持它,它在当前的 Linux 服务器上很常见。

但是没有一个用户工具可以很容易地显示文件创建时间,而 mactime 也没有捕捉到它。但是,使用 debugfs 可以检索创建日期。为此,Igor Moiseev 编写了一个名为 xstat 的便捷小脚本。

检查我的时间线,我可以知道第一个恶意的 Shell 何时出现在系统上。

检查日志

我可以在日志中找到一些对这些工具的调用,主要是来自亚洲 IP 地址,但由于 POST 数据没有被记录,我无法找到从 Apache 日志中上传这些 Shell 的文件。


寻找初始攻击向量

为了确定我是否能识别出最初的攻击,我使用了 Apache-Scalp。这是一个较旧的工具,但仍然有效。它主要通过正则表达式匹配已知攻击向量的 Apache 日志文件。

/opt/apache-scalp/scalp# python scalp.py -l 

/path/to/logs/access_log.processed.1_plain -f /path/to/default_filter.xml -a 

lfi,rfi,sqli,dt -p "25/Jun/2017;05/Jul/2017" --output /root/scalp --html

然而,在事件发生当天或之前,没有可疑的 sql 注入或 lfi / rfi 活动,这可能会与其中一个可疑文件发生关系。

检查 wordpress 插件,我发现在漏洞被上传一个月前,至少有一个 SEO 插件安装了一个严重的 Shell。

由于安装了很多插件,所以我编写了一个小脚本,来检查 wordpress 插件目录对 wpvulndb.com 的访问,并显示所有的漏洞。事实证明,有很多严重的漏洞,在没有足够的日志信息的情况下,很难追踪最初的向量。

[+] w3-total-cache

     * [UNKNOWN] W3 Total Cache 0.9.2.4 - Username & Hash Extract

        Fixed in: 0.9.2.5

        + http://seclists.org/fulldisclosure/2012/Dec/242

        + https://github.com/FireFart/W3TotalCacheExploit

     * [RCE] W3 Total Cache - Remote Code Execution

        Fixed in: 0.9.2.9

        + http://www.acunetix.com/blog/web-security-zone/wp-plugins-remote-code-execution/

        + http://wordpress.org/support/topic/pwn3d

        + http://blog.sucuri.net/2013/04/update-wp-super-cache-and-w3tc-immediately-remote-code-execution-vulnerability-disclosed.html

     * [CSRF] W3 Total Cache 0.9.4 - Edge Mode Enabling CSRF

        Fixed in: 0.9.4.1

        + http://seclists.org/fulldisclosure/2014/Sep/29

     * [CSRF] W3 Total Cache <= 0.9.4 - Cross-Site Request Forgery (CSRF)

        Fixed in: 0.9.4.1

注意,脚本没有检查主题或 wordpress 核心漏洞,这也可能包含严重的漏洞。

总结

根据这次服务器被攻击,我总结了如下几条:

  • 该系统已经被破坏了几个星期。在 Apache 日志的 Shell 中,最早的可见访问是在 7 月初。

  • 我识别了各种受损的 PHP 文件和一个 Windows 恶意软件。

  • 至少有三种类型的 Shell 被发现是攻击的指标。

  • Windows 恶意软件可能还没有传播。

  • 服务器没有显示出明显的更深的感染迹象,从用户帐户来看,没有找到 rootkit。

  • 攻击可能被限制在 Web Server 用户上,对于其他用户,我还没有发现任何受攻击的迹象。

  • 最初的攻击可能是过时的 wordpress 系统中最不安全的漏洞之一。

  • 没有迹象表明其他用户通过 Shell 访问了数据库或数据库凭据。但是,我不能排除有可能访问数据库的可能性。

  • 一些可能是来自亚洲 IPs 的恶意活动(Shell 访问)。

  • 除了清理系统中的恶意文件,我也应用一些优化手段,比如更改密码和证书,安装一个主机 id,执行定期扫描,主动监测服务器……

    不过,你永远不会得到 100% 的安全性,特别是当你的服务器已经被破坏时,你所能做的最好的事情就是检查每一个来自非官方的备份或脚本。

  • 高防服务器服务器租用,锐辉网络是专业的。

  • 文章转自站长工具,如有侵权,请联系删除