Linux服务器恶意代码防范轻量级手段
在上一篇《网络安全等保加固之Linux服务器恶意代码防范》文章，笔者介绍了在Linux环境下应用ClamAV进行恶意代码防范的方法。
但是，ClamAV始终显得有点过重，即使是每天运行一次，它在运行期间也容易和其它服务争夺内存资源。
笔者：国际认证信息系统审计师、软考系统分析师
而如果进一步考虑到应用服务器如果不对普通用户开放使用，不存储用户通过信息系统上传的文件，那么基本上可以认为ClamAV即使只是每天扫描一次，意义也不大。
这种情况下，我们可以考虑使用其它一些轻量级的恶意代码防范方法，比如chkrootkit和rkhunter。
在开始介绍之前，先补充一句（包括在上一篇讲述ClamAV的文章中也忘记提及的）：
如果认为服务器已经被恶意软件侵入，要实现有效检查，至少都要切换到单用户模式启动，更好的做法是从光盘等外部介质启动。否则恶意软件有很大可能会干扰这些检测防范手段。
首先还是简单解释一下rootkit。所谓rootkit，是指一系列的特殊的恶意程序，专门设计为尽可能长期维持潜伏在系统内，操纵主机和收集数据。
rootkit的设计目的使得检测rootkit是否存在是相当困难的，而且如果系统被控制，要想清除rootkit就更加困难。
大多数网管在发现服务器被安装rootkit后，都是采取格式化重装系统的方法，随后从确保是干净的备份中恢复还原数据。
当然，并不是所有的场合都能简单地格式化重装然后数据还原。因为从备份中还原就意味着必然要丢失一些数据，这就要取决于企业组织是否能承受这些数据丢失的痛苦----这很大程度上是能免则免的。
而且，恢复过程也不一定顺利，尤其是老旧信息系统，可能存在一些未被文档化也没有被适当备份的配置，导致数据恢复后无法正常使用。进一步地，还可能碰上老旧硬件不稳定因素使得恢复过程磕磕碰碰。
尽量避免（因从备份恢复而产生的）大量数据写入是老旧硬件能可靠使用的其中一条规律；更不说有些软件会基于硬盘分区信息生成许可秘钥，格式化重装后这秘钥就很可能成了废物。
啰嗦这么多，其实就是能避免重装系统还是要尽量避免。因此，我们可以尝试使用chkrootkit或者rkhunter这两个有针对性的软件，对主机的文件、系统日志进行检查，找出哪些系统文件被rootkit控制破坏了，然后对这些文件进行修复，使主机尽快恢复相对可靠的正常运行状态，然后再通过ClamAV或其它软件进行深入和全面的检查。
首先我们来看看 chkrootkit ：
chkrootkit 是一个有相当历史的恶意代码防范工具。和常规反恶意代码软件不同的是，chkrootkit只检查最重要的若干可执行文件，判断是否存在rootkit的情况。
chkrootkit当前版本是0.55版，2021年6月11日（巴西情人节）发布。
注意0.49及以下版本存在本地提权漏洞，不要使用。参考：
chkrootkit的程序源码包括以下组成：
-
chkrootkit: BASH脚本，检查系统程序是否存在被rootkit修改的痕迹
-
ifpromisc.c: 检查网络界面是否处于“杂听”模式（该模式用于从网络上抓包）
-
chklastlog.c: 检查是否存在lastlog被删除的情况
-
chkwtmp.c: 检查是否存在wtmp被删除的情况
-
check_wtmpx.c: 检查是否存在wtmpx被删除的情况（仅适用于Solaris操作系统）
-
chkproc.c: 检查是否存在LKM木马的痕迹
-
chkdirs.c: 检查是否存在LKM木马的痕迹
-
strings.c: 快速简单的字符串替换
-
chkutmp.c: 检查是否存在utmp被删除的情况
在功能上，chkrootkit每次更新都是有针对性地加入若干比较“关键”的rootkit或后门的检查，比如0.55版本新增检测包括：
-
Umbreon Linux Rootkit
-
Kinsing.A Backdoor
-
RotaJakito Backdoor
chkrootkit支持的操作系统包括Linux，Solaris，FreeBSD等。更详细的rootkit等恶意代码或后门程序的检测清单（共72类）可以到chkrootkit的网站查看。
本文章使用的是Rocky Linux 8，但chkrootkit并不包含发行版内，也没有包含在EPEL软件仓库内。因此，需要从源代码安装。
注意可靠的做法并不是在生产环境服务器上进行源代码编译过程，而是把源代码编译过程放在专门的开发机器上进行。完成编译后，把产生的执行文件复制到生产环境服务器上运行。
源代码编译过程如下（需要root用户）：
首先安装C++编译环境，相关要安装的包大约如下：
[root@rocky-vm ~]# dnf -y install gcc-c++ libstdc++-devel glibc-static glibc-devel make
然后下载chkrootkit源代码安装。但写稿时发现官方下载站（pangeia.com.br）可能域名没续费，下载不了，真是大跌眼镜。
于是转而从Fedora发行版那边找到了源代码的RPM包，通过rpmbuild来编译安装。
[root@rocky-vm ~]# wget https://download-ib01.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/c/chkrootkit-0.55-5.fc37.src.rpm
[root@rocky-vm ~]# rpmbuild --rebuild chkrootkit-0.55-5.fc37.src.rpm
中间一大堆编译信息忽略掉。然后安装编译后的RPM包：
[root@rocky-vm ~]# rpm -ivh ./rpmbuild/RPMS/x86_64/chkrootkit-0.55-5.el8.x86_64.rpm
错误：依赖检测失败：
/usr/bin/consolehelper 被 chkrootkit-0.55-5.el8.x86_64 需要
居然还需要一个依赖，这个consolehelper程序在usermode包里面，安装即可解决依赖问题：
[root@rocky-vm ~]# dnf install usermode
完成安装后，运行检查。chkrootkit程序在很短时间内即可完成扫描和报告的过程，占用资源是少得不可能再少。
[root@rocky-vm ~]# chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `crontab'... not infected
各种输出略掉。由于输出内容有一定篇幅，可以通过输出管道，通过grep命令过滤出 INFECTED（被感染）关键字，直接查看是否存在问题。
就如我在介绍ClamAV那篇文章那样，chkrootkit也可以放在cron作业中定时运行，并把输出重定向到特定的日志比如/var/log/chkrootkit.log。
还可以通过系统内部邮件方式，把输出结果发送给root用户再转发给专门的审计员账户，这样就可以很方便地在系统外通过接收邮件的方式查看扫描结果，不需要登入系统。
更具体的时候用方法，网上已经有大量的介绍，我这里就不做文抄公了。
第二个工具是rkhunter，网址：
RootKit Hunter，即“Rootkit 猎人”，功能和chkrootkit相似，但检测的内容更多，并且会默认向/var/log/rkhunter/rkhunter.log输出日志。
rkhunter的安装过程比chkrootkit要方便，因为rkhunter在EPEL仓库中存在。我们首先确认已经安装EPEL仓库：
[root@rocky-vm ~]# dnf -y install epel-release
[root@rocky-vm ~]# dnf -y install rkhunter
运行检测：
[root@rocky-vm ~]# rkhunter -c
[ Rootkit Hunter version 1.4.6 ]
Checking system commands...
Performing 'strings' command checks
Checking 'strings' command [ OK ]
Performing 'shared libraries' checks
Checking for preloading variables [ None found ]
Checking for preloaded libraries [ None found ]
Checking LD_LIBRARY_PATH variable [ Not found ]
Performing file properties checks
Checking for prerequisites [ Warning ]
/usr/bin/awk [ OK ]
/usr/bin/basename [ OK ]
/usr/bin/bash [ OK ]
/usr/bin/cat [ OK ]
/usr/bin/chattr [ OK ]
/usr/bin/chmod [ OK ]
/usr/bin/chown [ OK ]
/usr/bin/cp [ OK ]
/usr/bin/curl [ OK ]
/usr/bin/cut [ OK ]
/usr/bin/date [ OK ]
/usr/bin/df [ OK ]
/usr/bin/diff [ OK ]
/usr/bin/dirname [ OK ]
/usr/bin/dmesg [ OK ]
/usr/bin/du [ OK ]
/usr/bin/echo [ OK ]
/usr/bin/ed [ OK ]
/usr/bin/egrep [ Warning ]
/usr/bin/env [ OK ]
/usr/bin/fgrep [ Warning ]
省略大量输出，最后会给出检查汇总结果：
System checks summary
=====================
File properties checks...
Required commands check failed
Files checked: 133
Suspect files: 2
Rootkit checks...
Rootkits checked : 498
Possible rootkits: 0
Applications checks...
All checks skipped
The system checks took: 2 minutes and 21 seconds
All results have been written to the log file: /var/log/rkhunter/rkhunter.log
One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter/rkhunter.log)
对于给出的2个可疑文件（WARNING），可以在日志中看到详细的说明，比如：
[13:41:25] Warning: The command '/usr/bin/egrep' has been replaced by a script: /usr/bin/egrep: POSIX shell script, ASCII text executable
这并不是被rootkit控制，而是操作系统发行版不断变化，rkhunter还要跟上变化的问题。
另外，rkhunter的判断逻辑会对管理员手工修改过的文件标记为可疑，比如手工修改passwd或者group文件的情况，对于熟手管理员来说是很直接有效的操作，但这种操作没有产生对应命令（比如chgrp之类）的运行日志，所以有可能会被rkhunter的判断逻辑标记为可疑。
还有是对于一些变化得稍为频繁的系统脚本，尤其是网络界面控制脚本，rkhunter有可能会跟不上发行版的变化而误判为可疑情况。
但即使可能是误判，作为管理员也还是必须进行必要的检查。
继续还是最后的总结：
chkrootkit和rkhunter实际都还是被动防御手段，但由于轻量化的特点，对系统资源占用少，通过cron定时任务一天内多次运行也不会耗费多少资源，至于有无必要则取决于信息系统的具体运行使用情况。
另外，每次更新软件后（即使是从官方补丁镜像站获得更新），也应该马上运行一次chkrootkit或者rkhunter，或者两个都运行。
始终，要做好网络安全工作需要有偏执狂的态度，要假设所有的系统都可能存在恶意软件，没有任何一个系统是例外的。
本站微信订阅号：
本页网址二维码：