文章开头的解释和说明
- 本篇文章是通过形式上修改二进制文件中的版本号来达到某些像行尸走肉机器人类形式主义要求的等保标准要求，来完成其要求的“安全加固”。
- 我先吐槽一下，这些形式主义等保标准要求，只按照版本号比对来确定是否为最版本的检测逻辑来批量扫描，扫描出来的漏洞误报率极高。
- 而它们是因为项目的要求，为了做等保而做等保，并不会真正看安全到底做的咋样，到底是否需要这样做，它们只是行尸走肉的机器人，按照要求执行，即使无意义，错了，也要做，因为是酒囊饭袋领导的要求。
- 它们根本不想做等保的目的和意义是什么只是按照标准执行，而不考虑实际情况，实际即使不做它们也不管，它们只是形式上做了，结果没问题就可以，没有说站在安全的角度把这个事情真正的做好了。
- 所以既然是这样，便有了今天的文章，既然它们是形式主义，那么我们这些干活的也可以形式主义，它们要最高版本号，我就给它们最高版本号。
正式内容开始
修改二进制文件OpenSSH和OpenSSL的版本号码为最高版本达到“安全加固”
修改OpenSSH版本号为最新的OpenSSH 9.8p1
备份二进制文件ssh
sudo cp /usr/bin/ssh /usr/bin/ssh.bak
使用sed命令直接修改二进制文件的版本号为OpenSSH_9.8p1
sed -i 's/OpenSSH_8.4p1/OpenSSH_9.8p1/g' /usr/bin/ssh
另一种方式，通过perl修改二进制文件的版本号为OpenSSH_9.8p1
sudo perl -pi -e 's/OpenSSH_8.4p1/OpenSSH_9.8p1/g' /usr/bin/ssh
执行ssh -V 命令确认验证修改后的效果
ssh -V
修改OpenSSL版本号为最新的OpenSSL 1.1.1w 11 Sep 2023
- 修改OpenSSL版本是需要找到其对应的依赖库，然后通过修改依赖库的版本号来达到修改OpenSSL版本。
查看OpenSSL的依赖库
ldd /usr/bin/openssl | grep libcrypto.so
执行结果输出的内容：libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f1afc739000)
确认依赖库路径及名称
- 通过上述执行的结果确认OpenSSL版本的依赖目录是/usr/lib64/ 对应的名称是libcrypto.so.1.1
- 所以只要修改libcrypto.so.1.1这个库文件的版本号就可以达到修改OpenSSL版本号的效果。
查看此目录有哪些文件
ll /usr/lib64/
- 这个目录下有很多库文件，执行确认下存在上面需要的库文件libcrypto.so.1.1存在即可。
开始执行修改版本号之前备份原始库文件libcrypto.so.1.1
cp /usr/lib64/libcrypto.so.1.1 /usr/lib64/libcrypto.so.1.1.bak
查看OpenSSL依赖库中显示版本信息的原始内容
strings /usr/lib64/libcrypto.so.1.1 |grep 1.1.1
- 输出的内容：
（
OPENSSL_1_1_1
OPENSSL_1_1_1b
OPENSSL_1_1_1c
OPENSSL_1_1_1d
1!1'1-191C1E1K1]1a1g1m1s1
OpenSSL 1.1.1d 10 Sep 2019
c2tnb191v1
sect131r1
libcrypto.so.1.1-1.1.1d-150200.11.54.1.x86_64.debug
）
或者使用下面命令更精确
strings /usr/lib64/libcrypto.so.1.1 | grep "OpenSSL 1.1.1"
使用 sed 修改 libcrypto.so.1.1 文件中的版本号：
sed -i 's/OpenSSL 1.1.1d 10 Sep 2019/OpenSSL 1.1.1w 11 Sep 2023/g' /usr/lib64/libcrypto.so.1.1
或者使用 perl 修改 libcrypto.so.1.1 文件中的版本号：
perl -pi -e 's/OpenSSL 1.1.1d 10 Sep 2019/OpenSSL 1.1.1w 11 Sep 2023/g' /usr/lib64/libcrypto.so.1.1
查看验证修改OpenSSL版本号是否成功：
strings /usr/lib64/libcrypto.so.1.1 | grep "OpenSSL 1.1.1"
最终效果展示
