去年秋天，检查一个做运维的服务朋友半夜给我打电话，说他们一台对外提供API的器漏服务器CPU飙到100%，持续了四十分钟。程序他以为是检查流量突增，加了带宽，服务没用。器漏登上去一看，程序一个叫`kdevtmpfsi`的检查进程在疯狂吃资源，旁边还蹲着个`kinsing`。服务这是器漏典型的挖矿木马，通过Redis未授权访问漏洞进来的程序。他说了句话我印象很深：“我天天检查业务代码的检查漏洞，结果门是服务从服务器自己身上被踹开的。”

检查服务器漏洞，器漏跟检查自家门窗锁没锁是一个道理。但很多人只盯着应用层——SQL注入、XSS、CSRF这些东西。服务器本身的操作系统、中间件、开放端口、定时任务、SSH配置，反而容易被忽略。攻击者最喜欢的就是这种“灯下黑”。

从端口开始，别急着上扫描器

我习惯先跑一遍ss -tulnp或者netstat -tulnp，看看这台机器到底在监听什么。有次帮人看一台测试机，发现27017端口对公网开放，MongoDB没设密码。里面存着他们所有测试账号的明文密码。我问为什么开公网，回答是“方便家里调试”。

端口暴露是最直接的攻击面。数据库端口、Redis、Docker API、Kubernetes的6443，这些都不该出现在公网IP的监听列表里。如果必须远程访问，至少套一层VPN或者SSH隧道。用nmap从外部扫一遍自己的公网IP，比从内部看更真实——防火墙规则、云安全组、NAT，任何一层配置失误都会让内部服务裸奔。

补丁和内核，别等出事再升级

Linux发行版的安全更新经常被忽略。CentOS 7停更之后，很多机器还在跑老内核。Dirty Pipe（CVE-2022-0847）那会儿，一个普通用户就能提权到root，影响范围从5.8到5.16.11的内核。检查方法很简单：uname -r看内核版本，cat /etc/os-release看发行版，然后对照CVE数据库。

但升级内核有风险。生产环境不能随便重启。我一般建议先在测试机验证，用kexec或者livepatch做热修复。实在不行，至少把kernel.unprivileged_bpf_disabled这类缓解措施打开。

SSH：最容易被忽视的后门

很多人装完系统就改个端口，以为安全了。其实/etc/ssh/sshd_config里几个参数更关键：PermitRootLogin是不是yes？PasswordAuthentication有没有关？AllowUsers有没有白名单？我见过一台机器，SSH端口改成22222，但root密码是admin123，日志里每天几万次爆破记录。

更隐蔽的是~/.ssh/authorized_keys。攻击者进来之后，第一件事往往是加自己的公钥。检查的时候别只看/root/.ssh/，所有用户的home目录都要翻一遍。还有/etc/cron.d/、/var/spool/cron/，定时任务里藏个反弹shell太容易了。

写个脚本，但别只靠脚本

我给自己维护的几台机器写了个检查清单，用bash串起来：检查SUID文件、检查最近修改的二进制、检查异常网络连接、检查/tmp下的可执行文件。但脚本只能覆盖已知模式。有次发现一个挖矿程序伪装成systemd的子进程，名字叫[kworker/0:1]，脚本没报出来，是手动ls -la /proc/PID/exe才看到指向/tmp/.x/。

所以定期手动登上去看看，top、ps aux、lsof -i，花不了十分钟。服务器漏洞检查不是一劳永逸的事，是持续的习惯。就像那个朋友后来跟我说的：“现在每周五下午，我泡杯茶，挨个登机器看一遍。比出事之后熬夜强。”

最后提一句：别在服务器上直接跑来源不明的扫描器。有些“一键检测”脚本本身就是后门。用lynis、chkrootkit这些老牌工具，或者自己写。信任但验证，对服务器和对人一样。