服务器安全检测

一台业务服务器被入侵，服务往往不是器安全检从漏洞利用开始的，而是服务从一条没人看的日志开始。我见过太多案例——攻击者早在三个月前就拿到了权限，器安全检每天凌晨三点准时上传数据，服务而运维团队直到业务数据被勒索加密才反应过来。器安全检 服务器安全检测的服务核心就一句话：**在攻击者还没造成实质破坏之前，找出他们留下的器安全检痕迹**。这不是服务装个杀毒软件就能解决的事，也不是器安全检跑一次漏洞扫描就完事。真正有效的服务检测，得从三个层面下手。器安全检 先看系统层。服务登录记录是器安全检第一个要查的地方。`lastlog`和`wtmp`文件里藏着所有登录痕迹。服务攻击者通常会清理自己的登录记录，但清理动作本身就会留下新的痕迹——比如`bash_history`被清空，或者`/var/log/secure`文件大小异常归零。我遇到过一台服务器，`lastlog`显示只有root登录，但`/var/log/secure`里却有大量失败的SSH尝试记录。这不对劲，正常运维不会频繁输错密码。顺着查下去，发现攻击者用暴力破解拿到了一个弱口令账号，然后提权成root。 进程和端口检查同样关键。`ps aux`和`netstat -tlnp`能暴露大部分恶意程序。但别只看监听端口——有些后门程序会主动外连，不开放任何入站端口。比如用`lsof -i`查所有网络连接，再对比正常业务流量。我见过一个挖矿木马，伪装成系统进程`kworker`，CPU占用率却常年稳定在300%。不仔细看进程树，根本发现不了它。 文件层面的检测更考验耐心。攻击者喜欢把工具藏在临时目录、`/tmp`、`/var/tmp`或者`/dev/shm`里。这些地方权限宽松，清理时容易被忽略。用`find / -mtime -30 -type f`找出最近30天被修改的可疑文件，再配合`stat`看文件的创建时间和修改时间是否矛盾——比如一个系统库文件，创建时间居然是业务上线之后，这就不正常。 应用层是另一个重灾区。Web应用最常被利用的是文件上传和命令注入。检查`/var/log/nginx`或者`/var/log/apache2`的访问日志，重点看POST请求的URL参数里有没有`cmd`、`exec`、`shell`这些关键词。我处理过一个案例，攻击者利用某CMS的编辑器漏洞上传了一个PHP一句话木马，然后通过`?cmd=cat /etc/passwd`来执行命令。日志里这个请求只出现了一次，但返回状态码是200，而且响应大小异常——正常页面几十KB，那个响应只有几百字节，明摆着是命令执行结果。 数据库的检测容易被忽略。MySQL的`general_log`默认是关闭的，但如果打开了，里面记录着所有SQL语句。攻击者拖库时留下的SELECT语句，能直接暴露他们的目标。比如`SELECT * FROM users WHERE id=1 UNION SELECT ...`这种注入尝试，在日志里会留下明显的痕迹。另外，检查数据库的二进制日志和慢查询日志，有时能发现异常的数据导出操作。 最后说点实际的。检测手段再全，不如权限控制做得好。很多服务器被入侵，不是因为漏洞多高级，而是因为root密码太简单，或者不必要的服务对外开放。把SSH改成密钥登录，关掉不必要的端口，定期轮换数据库密码——这些基础操作能挡掉80%的常见攻击。 服务器安全检测不是一次性的工作，而是持续对抗的过程。你今天查完了，明天攻击者可能就用新手法进来。保持对日志的敏感，对异常行为的警觉，比用任何安全工具都重要。毕竟，工具是人写的，也有失效的时候，但你的观察力和判断力，是攻击者最难绕过的防线。