![奇怪的 Apache 访问日志](https://linux22.com/image/634428/%E5%A5%87%E6%80%AA%E7%9A%84%20Apache%20%E8%AE%BF%E9%97%AE%E6%97%A5%E5%BF%97.png)
我在我的 Apache 访问日志中看到了类似的重复请求,它们已经占用了我的所有 CPU。
我有一个正常的 WordPress 安装。我在 Apache 配置中所做的所有更改是将 DocumentRoot 从 /var/www/html 更改为 /var/www,以用于 ssl 和默认配置。
此外,请求中引用的文件(updatedll.jpeg)在我的服务器上不存在,也没有在 Web 应用程序的任何页面所提供的源代码中引用。
这会是安全威胁吗?这些实际上是什么?我能做些什么来阻止它们。
我更改了服务器的 IP 地址。他们仍然不断来访。这意味着有人实际上访问的是域名,而不是 IP 地址。
为什么我的服务器对这些请求发送 301?它不应该发送 404 吗?是不是因为 Wordpress 安装在我的根目录中,而 Wordpress 的 .htaccess 文件发送了 301 重定向?
我的磁盘访问日志似乎也间歇性地出现高峰。但实际上没有人访问该网站。除了以下这些之外,我没有看到任何访问日志。
另外,我发现所有请求似乎都来自以下 5 个 IP 地址之一。
201.4.132.43 - - [05/Jun/2014:07:35:08 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; BTRS103681; GTB7.5; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; AskTbATU3/5.15.29.67612; BRI/2)"
187.40.241.48 - - [05/Jun/2014:07:35:08 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB7.5; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
186.56.134.132 - - [05/Jun/2014:07:35:10 -0400] "GET /updatedll.jpg HTTP/1.0" 301 428 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
71.223.252.14 - - [05/Jun/2014:07:35:13 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; BTRS31756; GTB7.5; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; InfoPath.2)"
85.245.229.167 - - [05/Jun/2014:07:35:14 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MAAU; .NET4.0C; BRI/2; .NET4.0E; MAAU)"
更新
似乎有 32 个不同的 IP 地址正在访问我的服务器。
此外,命令“ngrep ‘GET /updatedll.jpg’ port 80”的输出如下:
T 75.172.162.70:1616 -> 162.243.34.213:80 [AP]
GET /updatedll.jpg HTTP/1.1..Accept: */*..Accept-Encoding: gzip, deflate..U
ser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;
BTRS31756; GTB7.5; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506
.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; InfoPath.2)..Connection: Kee
p-Alive..Host: www.reinventweb.com....
###############
T 85.245.0.83:65166 -> 162.243.34.213:80 [AP]
GET /updatedll.jpg HTTP/1.1..Accept: */*..UA-CPU: x86..Accept-Encoding: gzi
p, deflate..User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
GTB7.5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648;
.NET CLR 3.5.21022)..Host: reinventweb.com..Connection: Keep-Alive....
######
答案1
在 Google 上搜索文件名会显示几份日志文件,并且只有另一份,看起来像是上传日志来自某些服务。您应该能够判断该日志是否与您的站点相关,但我无法判断。
这五个 IP 地址均未出现在该上传日志中,因此这并不能说明什么。上传日志中的文件名在我看来是合法的。如果不知道内容,就无法判断这些文件的内容是否与其名称相符。
名为 的文件中原本可能包含什么updatedll.jpg
?我猜有人截取了如何更新某个 dll 的屏幕截图,并将其上传到服务以便与他人共享。共享可能不是在公共网络论坛上进行的,因为那样的话我就会找到更多相关内容。
为什么有人认为该文件驻留在您的主机上?我不知道。我发现将其包含\"%{Host}i\"
在 Apache 中很有用LogFormat
。
至于状态代码,您可以先尝试自己访问文件名,看看它在日志文件中的样子。如果您得到不同的状态代码,那么您自己对文件的请求和他们的请求之间一定有所不同。
如果你无法弄清楚如何重现完全相同的状态代码,那么请尝试生成其流量的数据包转储。你可以使用类似tcpdump -pni eth0 -s0 -Uw output.pcap 'host 201.4.132.43 || host 187.40.241.48 || host 186.56.134.132 || host 71.223.252.14 || host 85.245.229.167'
稍后,您可以使用 Wireshark 检查输出,以查看请求的具体内容。请记住使用更新版本的 Wireshark,以防有人真的试图利用 Wireshark 中的漏洞。一旦您看到了确切的请求,您就应该能够通过 telnet 命令重现答复。
答案2
您是根据域名进行重定向吗?例如从 example.com 重定向到 www.example.com?这也许可以解释 301 响应。
如果您的服务器响应 301,则可能不会造成太大损害。但是,某个页面上的图像链接可能已损坏。要找到该链接,您应该查看传入请求中的 Referer 标头。您可以从 Web 服务器记录 Referer,但直接查看流量可能更容易。
与 tcpdump 相比(kasperd 建议),我更愿意使用 ngrep:
ngrep 'GET /updatedll.jpg' port 80