本文描述一起电商网站首页篡改案，管理员小王对各方调查取证，几经周折终于对系统进程、TCP链接和Apache的访问日志，进行分析最终找到了原因。

关键日志：Apache访问日志

故事人物：小王（管理员）

一、阅读重点

本文探讨了众多网络安全的核心技术，这些技术在网络安全领域扮演着至关重要的角色，它们用于保障系统安全、识别并应对安全威胁。

1. 系统进程监控：通过使用`top`命令来监控系统进程和资源使用情况，以识别异常行为或资源占用过高的情况。
2. 并发连接监控：使用`ps`和`netstat`命令来查看Apache服务器的并发连接数，以评估服务器的负载和性能。
3. 网络连接状态分析：通过`netstat`命令分析网络连接状态，识别如TIME_WAIT、ESTABLISHED等状态的连接数量，以判断系统是否遭受攻击或存在配置问题。
4. 日志分析：检查Apache的`access_log`和`error_log`文件，以识别错误、攻击尝试或其他异常行为。
5. 文件完整性检查：检查Web根目录下的文件是否被非法修改，以确定网站是否遭受篡改。
6. 数据库安全检查：通过登录数据库并检查数据，以确保数据库安全，没有被非法访问或篡改。
7. 安全漏洞识别：通过手动检测、使用扫描工具、渗透测试、源代码检查等方法识别和修复潜在的安全漏洞。
8. 攻击类型识别：识别如文件包含攻击和目录遍历攻击等常见的网络攻击手段。
9. 调试工具使用：使用`strace`工具来跟踪和调试Apache进程，以识别导致段错误的具体原因。
10. Core文件生成：在系统出现段错误时，通过配置生成Core文件，以便后续分析和调试。
11. 安全加固处理：对网站进行安全加固，包括但不限于更新软件、修补漏洞、配置防火墙、加强访问控制等。

二、事件背景

小王刚刚入职一家电商网站，在网络运维部工作，职位是系统管理员，上一任管理员刚跳槽，公司的重担就落在一个新人肩上，成了“救火队长”，经常干着费力不讨好的工作，挣钱不多，每个月除去开销再给家中父母寄些钱，就所剩不多了。

圣诞节临近，公司决定进行今年最后一轮打折促销活动，为此各个部门都开始了紧锣密鼓的部署工作，小王所在的IT部门，除了日常维护，开始加紧为接下来的大量访问做一些系统扩容的准备工作。由于工作任务紧张，小王无暇顾及网络安全问题，处于“亚健康”状态的系统一直带病运行着，随着节日的临近，网站用户访问数量激增，网站流量也不停地刷新纪录。

然而好景不长，系统运行一段时间后，小王接到电话，称主页被篡改，且网站访问时断时续。公司老板得知此事，十分恼火，立即吩咐小王尽快处理好故障。小王接到任务后，开始了系统的取证工作。

1）检查系统进程

由于担心程序被替换，事先小王就在他的home目录下加密保存了一些重要的系统二进制文件的拷贝，例如md5、ps、top及netstat等。他先用top命令查看了系统进程列表。显示如下：

top命令结果显示，CPU利用率高达55.58%，原因何在？接着他重启了Apache服务器，这台物理服务器上运行大概10多个虚拟站点，在重启httpd的那一刻，网站打开速度很快，可几分钟后就不行了，而且 Load Average的值，很快就飙升到了30～40一直居高不下，不一会儿CPU利用率就全占满了，发生这种情况疑似受到了DOS攻击。

2 ) 查看并发数

通过下面的命令查看并发数量。

#ps -ef|grep httpd|wc -l

2458

结果表示Apache能够处理2458个并发请求。

接着，查看详细连接情况。

#netstat -nat|grep -i “80″|wc -l

2341

从以上结果看，没什么异常。“netstat –an”命令会打印系统当前网络连接状态，而grep -i “80″是用来提取与80端口有关的连接的， “wc -l”进行连接数统计。

注意：还有实用的命令来得到连接信息

#netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

FIN_WAIT_1 286

FIN_WAIT_2 360

SYN_SENT 3

LAST_ACK 32

CLOSING 1

CLOSED 36

SYN_RCVD 144

TIME_WAIT 2520

ESTABLISHED 2352

根据提供的netstat输出结果，我们可以分析出以下可能的问题和系统状态：

大量TIME_WAIT状态的连接：有2520个连接处于TIME_WAIT状态，这是最多的状态。当连接终止时，主动关闭的一方会进入TIME_WAIT状态，持续一段时间，以确保网络中所有可能的重复数据包都已消失。这个状态的连接数过多可能意味着：系统中有大量的短连接，比如Web服务器可能在短时间内处理大量请求。这可能是由于应用程序未能正确重用连接，导致不断创建新连接而非利用现有连接。

而ESTABLISHED状态连接较多（2352个），表明存在大量正在进行的网络连接，这虽属正常，但数量过多可能反映系统负载较高。

FIN_WAIT_1和FIN_WAIT_2状态的连接较多：分别有286和360个连接处于这些状态，这表明有很多连接正在被终止。这可能是正常现象，但如果数量持续增长，可能表明有大量的连接异常终止。

SYN_SENT和SYN_RCVD状态的连接较少：只有3个SYN_SENT和144个SYN_RCVD状态的连接，这表明系统主动发起的连接请求较少，而被动接收的连接请求较多。

没有显示任何LISTEN状态的连接：通常，服务器应用程序会有很多处于LISTEN状态的连接，等待新的连接请求。该状态的缺失可能表明没有服务器正在监听，或者netstat命令的输出被意外截断。

CLOSED状态的连接：有36个连接处于CLOSED状态，这表明这些连接已经完全关闭，没有数据传输。

CLOSING状态的连接：有1个连接处于CLOSING状态，这表明该连接正在等待远程TCP的确认。

分析结果显示，最突出的问题是TIME_WAIT状态的连接数量过多，这将引发系统资源浪费和端口耗尽的问题，特别是在系统短时间内处理大量连接的情况下。

针对此问题，可能需要进一步调查并采取优化措施，例如调整TCP参数以减少TIME_WAIT状态的持续时间，或改进应用程序的连接管理策略。其他状态的连接数量可能需要结合系统的实际运行情况和预期负载来评估是否正常。

3) 检查网站及数据库

随后，我们发现在Web根目录下，许多index.html和index.php文件被修改过。

#mysql -h localhost -u root –p

输入密码后仔细检查了各个网站数据库情况，也没有发现异常。随后又在浏览器输入phpinfo()测试页也都没发现问题。

“问题会出现在哪儿呢？”小王心想。一筹莫展的小王到机房外抽了根烟。

尽管网站被攻击的具体漏洞尚未明确，但通过手动检测、使用扫描工具、渗透测试、源代码检查和日志分析等方法，可以有效地识别和修复潜在的安全漏洞。小王意识到，通过分析Apache服务器的日志文件，可以追踪到攻击者的线索。因为即便攻击者尝试删除Web服务器上的IP记录，网关的日志文件仍然会保留这些关键信息，如远端IP地址等，为追踪攻击者提供了双重保障。随后他开始了获取httpd日志。

#cd /var/log/httpd

默认的http日志都在这里

＃wc -l access_log error_log

13129 access_log

125410 error_log

25670 total

输出结果表明：

access_log 文件包含 13,129 行。

error_log 文件包含 125,410 行。

total 表示两个文件的行数总和为138,539。

输出信息说明了以下几点：

日志文件大小：error_log 文件的行数远多于 access_log 文件，这表明 error_log 文件记录了更多的事件或错误。

错误频率：error_log 文件中大量的行数可能意味着网站（westshop.com）在一定时间内遇到了较多的问题或错误。

性能和稳定性：如果 error_log 中的行数异常高，表明网站的服务器或应用程序存在性能问题或稳定性问题。

日志管理：日志文件的行数和大小可能对日志管理策略产生影响，例如，需要定期清理或归档旧日志，以避免日志文件过大影响系统性能。

分析和监控：这些日志文件需要进一步分析，以确定错误的原因和模式，从而采取相应的措施来改进网站的运行。

在网络安全分析中，错误日志的详细分析和审查是至关重要的，以确保系统没有安全漏洞或遭受恶意攻击的迹象。

这时小王开始自言自语：“这很不正常。error日志不应该有这么大……”

他开始逐段查看error日志。

# head -50 error_log |more

[Sun May 5 13:42:45 2010] [notice] Apache/2.2.4 (UNIX) PHP/5.4.0 configured -- resuming normal operations

[Sun May 5 17:29:33 2010] [error] [client 80.11.134.231] File does not exist: /var/www/htdocs/scripts/..A../winnt/system32/cmd.exe

[Sun May 5 17:29:34 2010] [error] [client 80.11.134.231] File does not exist: /var/www/htdocs/scripts/.82e/./winnt/system32/cmd.exe

[Sun May 5 17:57:58 2010] [error] [client 210.113.198.122] File does not exist: /var/www/htdocs/scripts/..85c85c../winnt/system32/cmd.exe

[Mon May 6 23:33:15 2010] [notice] caught SIGHTERM, shutting down

[Sun May 5 13:42:45 2010] [notice] Apache/2.2.4 (UNIX) PHP/5.4.0 configured--esuming normal operations

[Mon May 6 23:33:47 2010] [error][client 48.82.130.78] Invalid URL in request GET /../../../../etc/passwd HTTP/1.1

[Mon May 6 23:33:52 2010] [error][client 48.82.130.78] Invalid URL in request GET /..HTTP/1.1

[Mon May 6 23:34:22 2010] [error][client 48.82.130.78] Invalid URL in request GET /../../../../..HTTP/1.1

[Mon May 6 23:34:26 2010] [error][client 48.82.130.78] Invalid URL in request GET /../../../../etc HTTP/1.1

[Mon May 6 23:34:35 2010] [error][client 48.82.130.78] Invalid URL in request GET /../../../../etc/ HTTP/1.1

……

分析提供的日志片段，我们发现它们属于Apache服务器的错误日志，揭示了服务器在处理特定请求时遭遇的若干问题。以下是对这些日志条目的简要解释：

[Sun May 5 13:42:45 2010] [notice] Apache/2.2.4 (UNIX) PHP/5.4.0 configured -- resuming normal operations

这条日志表明Apache服务器（版本2.2.4）在UNIX系统上配置了PHP（版本5.4.0），并且正在恢复正常操作。

[Sun May 5 17:29:33 2010] [error] [client 80.11.134.231] File does not exist: /var/www/htdocs/scripts/..A../winnt/system32/cmd.exe

这条日志显示了一个错误，客户端（IP地址80.11.134.231）尝试访问一个不存在的文件路径。这个路径看起来像是尝试访问Windows系统的cmd.exe文件，但由于路径中包含了UNIX系统的目录分隔符（/），这表明是一个跨平台的文件包含攻击尝试。

[Mon May 6 23:33:15 2010] [notice] caught SIGHTERM, shutting down

这条日志表明服务器接收到了一个SIGTERM信号，通常用于请求程序关闭。

[Mon May 6 23:33:47 2010] [error][client 48.82.130.78] Invalid URL in request GET /../../../../etc/passwd HTTP/1.1

这条日志记录显示，一个来自IP地址48.82.130.78的客户端，试图通过GET请求非法访问/etc/passwd这一高度敏感的系统文件，该文件存储着系统的用户信息。这一行为明显透露出有人正企图窃取系统用户数据的意图。

其他类似的日志条目也显示了类似的尝试，都是试图通过构造特殊的URL来访问系统文件。

这些日志条目无疑表明，你的服务器已经多次遭受了安全威胁，特别是文件包含攻击和目录遍历攻击这两种常见的网络攻击手段。

他不敢相信自己的眼睛，不会吧，怎么会有 /winnt/system32/cmd.exe他开始怀疑系统中了蠕虫或是被攻击了。随后他又查看了第二批日志，部分内容如下：

#tail -50 error_log |more

[Mon May 22 11:45:11 2010] [notice] child pid 2880 exit signal Segmentation fault (11)

[Mon May 22 11:46:01 2010] [notice] child pid 2908 exit signal Segmentation fault (11)

[Mon May 22 11:47:26 2010] [notice] child pid 2936 exit signal Segmentation fault (11)

[Mon May 22 11:47:38 2010] [notice] child pid 2984 exit signal Segmentation fault (11)

……

当遇到了“Segmentation fault (11)”错误。这个错误通常表示程序试图访问其内存空间中未分配（或不允许访问）的部分，导致操作系统终止该进程以防止系统崩溃。

当前系统中每分钟都要产生一条Segmentation fault报错信息

“Apache通常不会出现这样的Segmentaion fault故障，这种情况到底出现了多少次呢？”小王心想。随后输入下面命令查看：

#grep Segmentation error_log |wc –l

65196千多条，“这可不是好兆头。 小王突然想到了可以使用调试工具strace来实时疏通apache的“脉络”。接着他很快写出了一个可执行脚本apache_debug.sh

#!/bin/sh

while [ "1" == "1" ]; do

APACHE_LIST=`ps -ef | grep apache | grep ^www | awk '{ print $2; }'`

for i in $APACHE_LIST; do

if [ ! -e $i.log ]; then

echo "strace $i"

strace -p –v $i 2> $i.log &

fi

done

echo "wait"

sleep 60s

done

注意：这是个循环脚本，其目的是监控Apache服务器的进程，并为每个没有日志文件的进程创建一个strace日志。脚本会产生大量日志，实际中大家慎用。以下是脚本的逐行解释：

#!/bin/sh：这是一个shebang行，告诉系统这个脚本应该用哪个解释器来执行，这里是sh。

while [ "1" == "1" ]; do：这是一个无限循环的开始，只要条件为真（在这里总是为真），循环就会一直执行。

APACHE_LIST=ps -ef | grep apache | grep ^www | awk '{ print $2; }'``：这行命令获取所有Apache进程的列表。ps -ef列出所有进程，grep apache过滤出包含'apache'的行，grep ^www进一步过滤出以'www'开头的行（这通常表示Apache的子进程），awk '{ print $2; }'则打印这些行的第二列，即进程ID。

for i in $APACHE_LIST; do：开始一个循环，遍历所有Apache进程ID。

if [ ! -e $i.log ]; then：检查当前进程ID对应的日志文件是否存在。

echo "strace $i"：如果日志文件不存在，先打印出将要执行的strace命令。

strace -p –v $i 2> $i.log &：执行strace命令，附加到进程ID为$i的进程，-p参数表示附加到进程，-v参数表示详细模式，2>将标准错误重定向到日志文件，&表示将这个命令放到后台执行。

fi：if语句的结束。

done：for循环的结束。

echo "wait"：打印出"wait"，表示脚本将等待一段时间。

sleep 60s：脚本暂停60秒。

done：while循环的结束。

在运行Apache后，就接着运行脚本apache_debug.sh ,这个脚本把strace每一个，由于apche程序在运行一段时间后会自动崩溃（短短１分钟时间）这个脚本的目的就每过一分钟就检查一下当前的apache，这样一来就会发现问题。

接着我们就等着Segmentation fault发生来看看进程ID的内容，很快就找到了，下面就是部分strace程序的输出内容：

setsockopt(42, SOL_SOCKET, SO_RCVTIMEO, "\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

rt_sigaction(SIGSEGV, {0x43ab80, [SEGV], SA_RESTORER|SA_RESTART, 0x2b594e0ad4f0}, {0x2b5951de9ca0, [SEGV], SA_RESTORER|SA_RESTART, 0x2b594e0ad4f0}, 8) = 0

rt_sigaction(SIGFPE, {SIG_DFL}, {0x2b5951de9ca0, [FPE], SA_RESTORER|SA_RESTART, 0x2b594e0ad4f0}, 8) = 0

{0x2b5951de9ca0, [ABRT], SA_RESTORER|SA_RESTART, 0x2b594e0ad4f0}, 8) = 0

fstat(2, {st_mode=S_IFREG|0640, st_size=2396024, ...}) = 0

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b5959ea1000

kill(3204604, SIGSEGV)                  = 0

rt_sigreturn(0x30e5fc)                  = 12

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

chdir("/etc/apache")                   = 0

rt_sigaction(SIGSEGV, {SIG_DFL}, {0x43ab80, [SEGV], SA_RESTORER|SA_RESTART, 0x2b594e0ad4f0}, 8) = 0

kill(3204604, SIGSEGV)                  = 0

rt_sigreturn(0x30e5fc)                  = 12

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

Process 3204604 detached

从这些输出中可以看出，程序在执行过程中遇到了段错误，并且尝试处理这个信号。这通常是由于代码中存在bug，比如引用了空指针或者数组越界等。

他心想“访问日志中是不是有什么线索能告诉我这台机器到底发生了什么问题呢？”

#tail -50 access_log |more

192.168.1.215 – [21/Oct/2010:11:57:56 - 0400] “POST /home.php HTTP/1.1 “200 65401

192.168.1.215 – [21/Oct/2010:11:57:58 - 0400] “POST /home.php HTTP/1.1 “200 3870

192.168.1.215 – [21/Oct/2010:11:57:59 - 0400] “POST /home.php HTTP/1.1 “200 84404

192.168.1.215 – [21/Oct/2010:11:58:01 - 0400] “POST /home.php HTTP/1.1 “200 65401

192.168.1.215 – [21/Oct/2010:11:57:52 - 0400] “POST /home.php HTTP/1.1 “200 3970

……

分析日志之后，小王认为这都与POST命令有关，但他依然不知道是什么原因导致了这种故障。

三、安全事件分析

导致Segmentation fault故障的原因？

在Linux系统中，Apache服务器的error_log文件中出现Segmentation fault (11)错误通常表示Apache的某些子进程在尝试访问它们没有权限访问的内存区域时被操作系统终止。这种错误通常是由以下原因引起的：

1. 攻击尝试：

以上文章中提到了多次尝试访问不存在的文件路径，这些路径看起来像是跨平台的文件包含攻击尝试，例如尝试访问`winnt/system32/cmd.exe`。

还有尝试通过构造特殊的URL来访问系统文件，如`/etc/passwd`，这些行为表明服务器遭受了安全威胁。

2. 非法请求：

分析中发现日志显示有客户端发送了无效的URL请求，这可能是攻击者试图利用服务器的漏洞。

3. 内存访问问题：

从日志中发现`Segmentation fault`错误通常表示程序试图访问其内存空间中未分配（或不允许访问）的部分。

4. 代码或配置问题：

如果Apache服务器加载了有加载错误模块或Apache配置不当设置，都可能会导致在处理请求时出现内存访问错误。

5. 外部因素：

- 本案例中提到了使用`strace`工具来跟踪Apache进程，这表明管理员正在尝试诊断问题。如果`strace`的使用方式不当或在特定情况下触发了某些条件，也可能导致段错误。

6. 系统资源限制：

- 如果如内存不足，Apache在处理请求时可能会因为无法分配足够的资源而出现段错误。

上述原因都有可能导致了`Segmentation fault`问题，到底怎么回事小王还是无法判定，不过可以确定的是，服务器遭受了多次攻击尝试，并且存在内存访问错误。解决这个问题需要找一个资深专家来进一步的调查和分析。

各位读者，当您看完了这段案例，通过小王对事件的分析，有什么想法？先尝试回答下面3个小问题。

1.通过分析在所查询到得日志文件中可能出现了什么攻击？

2.如何实现在系统Apache出现段错误时输出到 Core文件？

3.小王应该对他的网站进行哪些安全加固处理？

如果你对揭开这个谜团感到好奇，那么我建议你可以深入阅读《Unix/Linux网络日志分析与流量监控》这本书籍。这本书详细地介绍了如何分析Unix和Linux系统中的网络日志，以及如何有效地监控网络流量，帮助你更好地理解系统运行的细节和潜在的安全问题。

文中介绍的案例，摘自国内首部网络日志分析领域的权威著作《Unix/Linux网络日志分析与流量监控》。这部计算机领域的经典之作，已经畅销长达十年之久，深受网络安全专业人员、企业信息化主管以及网络攻防演练红蓝战队的青睐。JD购书地址：https://item.jd.com/10026499621877.html