运维笔记:流量分析,顺便复习静态、动态资源的加载

真的是计划赶不上变化,世上请求千千万,每隔一段时间总要处理新常态。我在前置文章,运维笔记:第一次开发WordPress插件里提到,因为网站部署在云主机上,没有命令行功能,因此自动报警插件完全是通过WP内置的动作钩子来实现的。这样一来就无法与服务器进行交互,但403、503记录我每个月初都会用脚本处理一遍,没有遇到过例外状况。可是,例外总是用来打破的,昨天的一条请求,着实是让我猝不及防。

一、缘起

先来看一下这是个什么请求:

45.138.16.116 - - [13/Mar/2024:22:27:00 +0800] "GET /wp-includes/js/wp-emoji-release.min.js HTTP/1.1" 200 5052 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"

这个GET请求,请求的是WP核心目录下的一个JS文件,wp-emoji-release.min.js。就从这条记录看,这个请求主要有两大特征:

1、机器人特征明显。wp-emoji-release.min.js这个文件,是管理员登陆后进入/wp-admin/(也就是网站仪表盘)才会加载的,不会被孤立访问。而且在正常访问下,这个文件的URL后会带?ver=版本控制号,而不是像这条请求一样直接请求原始文件。

2023年404记录的引荐来源统计

2、恶意流量特征明显。这条请求的referrer是www.google.com,正常从GOOGLE引荐来的流量,referrer会带有https://协议名。如上图,我曾经做过2023年的404记录referrer统计,www.google.com引荐来源可是荣登第四名。

也就恰好是这个referrer,www.google.com,因为劣迹斑斑,它在我的报警插件referrer匹配列表中。我正是看到了这个referrer,匹配报警插件日志时,却没有找到对应的触发记录,才多留了个心眼。这就是我烦恼的地方了:这个请求恶意特征明显,没有触发报警插件;因为返回了200状态码,没有直接被视为错误请求,容易被忽略。

二、试验

这条流量毫无疑问是某个脚本或者工具发出的,用于URL刺探。可是它就这么长驱直入了,没有被拦截,没有被报警插件发现。报警插件绑定的是WP的init钩子,我于是取消插件IP白名单,做了几个试验来情景复现,看什么情况下能触发WP钩子(referrer不变):

1、直接访问wp-emoji-release.min.js

请求成功,返回200状态码,WP没有被加载,更没有触发插件。

2、把文件更名为wp-emoji-release.min1.js后访问

返回404状态码,加载WP,触发插件。

三、复习

那为什么打错了文件名反而能加载WP,触发init钩子呢:

因为在 WordPress 的请求处理流程中,当系统检测到请求的资源(如 JavaScript 文件)不存在时,它会将请求交给 WP::handle_404() 方法来处理。在这个方法中,WordPress 会设置 HTTP 响应状态为 404 并返回 404 页面。同时,由于这是在初始化过程中发生的,因此会触发 init 钩子。

而情况1中,直接请求js文件不会加载WP,则是因为:

当用户直接请求静态资源(如 JavaScript 文件)时,Web 服务器(如 Apache 或 Nginx)会直接处理这个请求并返回文件内容。在这种情况下,请求并不会经过 WordPress 的处理过程。WordPress 通常用于处理动态内容,如页面、文章和用户交互等。但对于静态资源文件,服务器会尝试直接提供这些文件,而不会将请求传递给 WordPress。

静态资源是指在服务器上存储的、不会在请求过程中发生变化的文件,例如图片、CSS 文件、JavaScript 文件、字体文件等。这些文件在每次请求时都会以相同的方式呈现给用户,不受用户或服务器状态的影响。

相比之下,动态资源是在每次请求时根据用户或服务器状态生成的内容。例如,动态资源可以是由服务器端脚本(如 PHP)生成的 HTML 页面、根据用户输入生成的数据等。动态资源的内容可能因为不同的请求或用户状态而发生变化。

PS. 应该有人会发现,本站的文章链接后缀是.html,但这其实是伪静态。Play a trick!

发布者

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注