云服务器安全自查：每项检查的命令示例

云服务器安全自查最痛苦的不是不知道要做什么，而是知道要做却拿不出可执行的命令。很多人手里攥着一份几十项的检查清单，真到了服务器面前却只能靠肉眼扫配置文件，或者复制粘贴网上搜来的过时脚本。这种"有清单无弹药"的局面，让安全自查变成形式主义。

账号与权限：从whoami开始摸底

先搞清楚自己站在什么位置上。登录后第一条命令永远是确认身份和权限边界：

whoami && id && groups

接着排查有哪些账户拥有系统级权限，重点看UID为0的非root账户：

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

sudo权限清单往往藏着历史遗留的后门，这个文件要逐行审：

cat /etc/sudoers
getent group sudo

最近30天谁登录过、从哪来、失败了几次，这些痕迹不会撒谎：

last -a | head -20
lastb | head -10
grep "Failed password" /var/log/auth.log | tail -20

网络暴露面：用netstat画一张实时地图

云厂商控制台看到的端口开放情况，和服务器实际监听的往往有出入。先拿netstat做交叉验证：

ss -tulnp | grep -v "127.0.0.1"
netstat -tulnp | grep LISTEN

对外暴露的服务进程要逐个确认必要性，尤其警惕那些监听0.0.0.0的陌生端口。iptables或firewalld规则也要对照检查：

iptables -L -n -v
firewall-cmd --list-all

文件完整性：找到那些被遗忘的后门

Web目录里有没有异常的可执行文件？上传目录是否被塞了webshell？用find做模式扫描比肉眼可靠得多：

find /var/www -type f -name "*.php" -mtime -7
find /var/www -type f -perm /111 | grep -E "(upload|cache|tmp)"

敏感配置文件的可读范围经常设置过宽，.env、config.php这类文件不该被任意用户读取：

find /var/www -name "*.env" -o -name "*config*" | xargs ls -la

日志审计：grep是最低成本的安全分析工具

SSH暴力破解的痕迹藏在auth.log里，统计IP出现频率能快速定位攻击源：

grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

Web访问日志中的异常状态码往往预示扫描行为或利用尝试：

awk '$9 ~ /^4[0-9][0-9]$/' /var/log/nginx/access.log | tail -20
awk '$9 ~ /^5[0-9][0-9]$/' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn

计划任务的执行记录容易被忽视，但这里经常是持久化攻击的落脚点：

cat /var/log/cron
find /etc/cron* -type f -mtime -7

补丁与软件版本：把yum和apt变成安全检查器

最后别忘了软件层面的暴露面。内核版本、关键服务版本、已安装的安全更新，这些都可以用包管理器快速盘点：

yum updateinfo list security
apt list --upgradable
dpkg -l | grep -E "(openssl|openssh|nginx|mysql)"

安全自查的本质不是追求完美覆盖，而是建立可重复、可对比、可追责的执行标准。把这些命令按周或按月跑一遍，输出结果存档比对，比任何商业扫描报告都更能反映真实的安全水位。