CentOS服务器在跑过半年甚至更久之后，最容易出现的问题往往不是一下子崩掉，而是磁盘inode悄悄耗尽、定时任务被篡改、SSH登录出现异常空档、日志里躺着大量失败尝试却没人去看。常态化安全巡检的目的不是等出事了再救火，而是把那些已经发生但还没爆发的隐患提前揪出来。下面直接按实际操作顺序讲完整流程，每一步都可以在CentOS 7和CentOS 8系上直接执行。

一、先锁定当前系统基础状态

巡检第一步不是扫漏洞，而是先搞清楚自己正在巡检的这台机器到底处于什么版本、什么内核、跑了多久、有没有异常重启。执行下面几条命令：

cat /etc/redhat-release
uname -r
uptime
last reboot | head -n 10

如果uptime显示刚重启过，但运维团队没人操作过，就要立刻提高警惕。last reboot能帮你确认最近几次重启时间点，结合/var/log/messages里的关机记录，可以判断是人为重启还是内核崩溃或掉电。CentOS 8已经停止维护，如果生产环境还在跑CentOS 8，建议在巡检报告中单独标注迁移风险，这不是安全问题，但会直接影响后续补丁能力。

二、账户与认证层面排查

账户是服务器被入侵后最常被动手脚的地方。先看/etc/passwd里有没有UID为0的异常账户：

awk -F: '($3==0){print $1}' /etc/passwd

正常情况只应该有root。如果出现其他名字，立即检查该账户创建时间和登录记录。接着看可登录账户列表：

cat /etc/passwd | grep -v nologin | grep -v false

重点核对是否有陌生账户，以及是否有业务账户被赋予了/bin/bash。再检查空密码账户：

awk -F: '($2==""){print $1}' /etc/shadow

空密码账户一旦存在，等于大门敞开。然后看SSH配置，确认是否禁止root直接登录、是否关闭密码登录、是否限制登录用户：

grep -E "PermitRootLogin|PasswordAuthentication|AllowUsers|AllowGroups|Port" /etc/ssh/sshd_config

如果生产环境必须用密码登录，至少要确认密码复杂度策略在/etc/pam.d/system-auth里已启用。很多CentOS默认没有装pam_pwquality，建议检查：

rpm -qa | grep pam_pwquality

没有的话，高强度密码策略基本等于空谈。

三、登录行为与失败记录分析

账户配置看完，接下来看实际登录行为。先查最近登录成功的记录：

last -n 30

注意登录来源IP、登录时间是否与业务规律吻合。再查登录失败记录：

lastb -n 50

如果lastb刷出来大量来自同一个IP的失败尝试，说明正在被暴力破解。CentOS默认没有安装lastb所需的btmp文件记录，如果没有输出，先执行：

touch /var/log/btmp
chmod 600 /var/log/btmp

然后检查SSH日志中的失败登录：

grep "Failed password" /var/log/secure | tail -n 30

对于高频失败IP，直接在firewalld里封禁：

firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=攻击IP reject'
firewall-cmd --reload

如果失败尝试来自多个IP且频率很高，建议临时修改SSH端口或启用fail2ban。fail2ban在CentOS上可以通过EPEL源安装，配置简单但效果直接。

四、进程与网络连接巡检

很多木马和后门会以进程形式常驻，或者监听异常端口。先看所有监听端口：

ss -tulnp

对照业务需要，如果出现不明端口在监听，尤其是高位端口，立即用以下命令定位进程：

lsof -i :端口号

再查看所有进程，重点关注CPU或内存占用异常但名字看起来正常的进程：

ps aux --sort=-%cpu | head -n 20
ps aux --sort=-%mem | head -n 20

有些挖矿程序会伪装成类似系统进程的名字，比如kworkerds、systemd-networkd（注意多了个d）。检查进程的启动路径：

ls -l /proc/进程PID/exe

如果路径指向/tmp、/dev/shm或/var/tmp，基本可以判定为恶意进程。再检查当前所有外部连接：

ss -antp

重点看ESTABLISHED状态里有没有连接可疑IP。对于业务不需要的出站连接，可以结合iptables或firewalld做出站限制。

五、定时任务与自启动项深度检查

很多入侵者拿到权限后，会通过crontab维持持久化。先看系统级定时任务：

cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/

再检查各用户的crontab：

for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l 2>/dev/null; done

特别注意包含curl、wget、base64、/tmp路径的定时任务。很多挖矿木马会把下载脚本放在cron.hourly里。接着检查systemd自启动服务：

systemctl list-unit-files --type=service | grep enabled

逐个核对enabled服务是否都是业务所需。对于不认识的service，用以下命令查看具体内容：

systemctl cat 服务名

同时检查/etc/rc.local和/etc/rc.d/rc.local是否有追加的启动命令：

cat /etc/rc.local

CentOS 7之后rc.local默认没有执行权限，如果发现被加了执行权限且里面有陌生命令，要立即处理。

六、文件完整性与关键目录权限核查

文件被篡改是安全事件的重要特征。先检查关键系统命令是否被替换：

rpm -Va | grep -E "bin|sbin|usr/bin|usr/sbin"

输出中如果有5（MD5校验失败）或M（权限被改），要逐个确认。再看/tmp、/var/tmp、/dev/shm这些可写目录里有没有可疑文件：

ls -la /tmp /var/tmp /dev/shm

重点关注隐藏文件、以点开头的目录、以及名字带空格或特殊字符的文件。检查/root目录权限：

ls -ld /root

正常应为700。再看/etc/passwd和/etc/shadow权限：

ls -l /etc/passwd /etc/shadow /etc/group /etc/gshadow

passwd正常是644，shadow是000或400。如果shadow被改成644，所有用户都能读哈希，属于严重配置错误。

七、日志完整性与异常审计

日志是安全巡检的核心证据来源。先确认rsyslog或systemd-journald在正常运行：

systemctl status rsyslog
systemctl status systemd-journald

检查secure日志是否有被清空的痕迹。如果secure文件大小异常小或者时间跨度不对，可能被人为清理过。查看日志中是否有sudo提权记录：

grep "sudo" /var/log/secure | tail -n 50

确认所有sudo操作都是运维人员所为。再检查是否有账号被添加或删除的记录：

grep -E "useradd|userdel|passwd" /var/log/secure | tail -n 30

如果发现useradd记录但团队没人操作过，基本可以判定已被入侵。同时建议检查/var/log目录整体占用：

du -sh /var/log/*

有些攻击会导致日志爆炸式增长，把磁盘写满，进而引发服务异常。

八、内核与软件漏洞快速排查

CentOS的补丁更新是安全巡检中必须做的一环。先看当前可更新的安全相关包：

yum check-update --security

如果输出中有kernel、openssl、openssh、glibc等关键包，建议尽快安排维护窗口升级。查看当前内核版本与已安装内核：

rpm -qa | grep kernel

确认正在使用的内核不是已淘汰的旧版本。CentOS 7的3.10内核虽然老，但Red Hat会持续移植安全补丁，关键是要保持yum更新。对于CentOS 8，由于官方源已停止维护，需要切换到Vault源或迁移到Rocky/Alma才能继续获取补丁，这一点必须在巡检报告中明确写出。

九、防火墙与SELinux状态确认

很多运维为了省事会直接关掉防火墙和SELinux，这在生产环境属于高风险操作。先看防火墙状态：

systemctl status firewalld
firewall-cmd --list-all

确认开放端口与业务匹配，没有多余端口暴露。再看SELinux：

getenforce

如果是Disabled，建议评估开启Enforcing的可行性。如果业务确实无法在Enforcing下运行，至少要开启Permissive并定期检查audit日志，而不是直接关掉。SELinux能有效限制入侵者在拿到webshell后的横向操作，关掉等于自断一臂。

十、输出巡检报告与整改跟踪

巡检做完不算完，必须形成可跟踪的整改清单。报告至少包含以下字段：检查项、当前状态、风险等级、整改建议、责任人、整改期限。对于高风险项，比如发现异常账户、可疑进程、SSH配置错误，应当天处理。中风险项如补丁未更新、日志策略不完善，可纳入下一维护窗口。低风险项如SELinux未开启、密码策略未强制，可列入长期加固计划。每次巡检后更新报告，下次巡检时先复核上次整改项是否真正落地。

常态化安全巡检的关键在于固定周期和固定动作。建议至少每月执行一次完整巡检，每周执行一次快速巡检，快速巡检只做账户、登录失败、进程、端口、定时任务这五类最容易被利用的检查。把上面的命令整理成脚本，配合邮件或消息推送，可以大幅降低人工遗漏的概率。CentOS服务器只要把这套流程跑顺，大部分常见入侵和配置风险都能在造成实际损失前被发现。