MySQL/GreatSQL 应对安全扫描的绝招-CSDN博客

用魔法打败魔法

背景

有些所谓的安全扫描，其实只是简单判断 MySQL/GreatSQL 版本号，全然不考虑是否真的存在相应的风险，但是为了安全合规又不得不做出应对。

思路

针对这种简单粗暴的扫描手段，解决方案有这么几种：

升级版本。这个最为彻底，但工作的代价最大。
重新编译二进制包，在编译时自定义版本号。这个方法的代价较小，但治标不治本，而且对很多人来说，编译也不是轻松的事。
新增代理层。利用代理层来响应版本信息。此方法代价较小，但可能会导致性能损失，并且不是所有的代理层都支持修改版本号。
最后一种就是本文要说的大招，直接用 sed 修改版本号。这个方法代价最小，操作起来也最容易。

实施

1.先利用 telnet 确认当前的版本号信息

$ telnet 127.0.0.1 3306
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
M
8.0.32-26�,BjNjkf>�I58DL?
1caching_sha2_password

2.动手修改之前，务必做好物理备份

$ cd /usr/local/GreatSQL-8.0.32-26-Linux-glibc2.28-x86_64/bin/
$ cp mysqld mysqld-803226

3.利用 sed 修改替换 MySQL/GreatSQL 版本号

$ cd /usr/local/GreatSQL-8.0.32-26-Linux-glibc2.28-x86_64/bin/
$ sed -i 's/8\.0\.32/8.0.40/ig' mysqld

注意，直接用 sed 替换的约束条件如下

替换的字符串长度必须与原字符串相同，否则可能会破坏二进制结构。例如不能把 "8.0.32" 替换成 "8.01.32"，因为前后长度不一致。
若新版本号长度不足，可以用 "0" 或空格补齐。例如将 "8.0.32" 替换成 "8.4.2 " 或 "8.4.02"。两种方式都能正常启动：

Server version:  8.4.02 GreatSQL, Release 26, Revision a68b3034c3d
Server version:  8.4.2  GreatSQL, Release 26, Revision a68b3034c3d

用上述方法完成版本号修改后，最好在测试环境中先行测试一段时间，尤其是利用自带的 MTR 组件完成一次回归测试，以及一定时长的压力测试。测试没问题了再真正替换线上生产环境。

采用本文的方法，启动修改后的 mysqld 进行压力测试，已经稳定运行20多天

...
Server version:  8.0.40-26 GreatSQL, Release 26, Revision a68b3034c3d
...
Threads: 14  Questions: 5401434892  Slow queries: 6624902  Opens: 3843  Flush tables: 4  Open tables: 669  Queries per second avg: 2694.014

看起来这个魔法似乎可行。

以上。

Enjoy GreatSQL :)

文章推荐：