简介面向运维工程师、系统管理员及安全从业者的服务器安全巡检实操文档聚焦如何通过定期人工检查发现系统漏洞与日常管理隐患适合需要建立规范化巡检流程的初中级运维人员参考。资源包共1个docx文件约163KB采用A4打印排版、可编辑的Word格式便于直接套用或按单位情况调整。内容围绕巡检重要性与关注点展开逐项梳理系统服务、账户权限、安全策略、防火墙、防病毒系统、操作系统补丁、密码安全、应用安全与磁盘权限等检查维度并给出从远程连接、进程比对、可疑账户禁用、服务核查、日志备份分析到数据库与备份任务验证的九步操作流程附异常现场保护与跟踪原则及巡检表模板。已有168人学习可帮助读者快速搭建可落地的服务器安全巡检清单与记录体系。1. 巡检做完却说不清“哪里不对”一份表格救不了没有基线的服务器凌晨两点被告警叫醒登录服务器翻了一圈top、netstat、/var/log/secure进程看着都眼熟端口也没多出什么可心里就是不踏实——这种“感觉有问题但拿不出证据”的状态是安全巡检里最折磨人的场景。很多人把巡检做成打卡表格填满、时间签上、文件归档真出事时却翻不出一份能对比的原始记录。问题不在态度在于巡检缺少“基线”这个参照物。这份《服务器安全巡检内容及方法》文档把巡检拆成用户和组、系统服务、系统进程、防火墙、防病毒、系统日志、数据库、备份、磁盘权限、上传目录、FTP 权限、补丁升级等检查点并配了一张可填写的巡检表。它适合刚接手服务器运维的开发者也适合需要把巡检从“凭经验”变成“有据可查”的老手。下面按巡检中最常翻车的几类故障把根因和操作路径讲透。2. 进程和服务对不上号可疑进程排查与基线比对2.1 为什么“看着眼熟”是最危险的判断巡检第一步是看进程但绝大多数人栽在“眼熟”上。攻击者留下的进程往往伪装成系统组件名比如把sshd写成sshd后面多一个空格或者用kworker之类的内核线程名做掩护。文档里强调“比对异常情况”关键词是比对——没有上线前的系统状态镜像你根本无从比。常见做法是在服务器交付使用前把ps、ss、systemctl list-units的输出各存一份到离线位置作为基线快照。之后每次巡检拿当前输出和基线做 diff多出来的、路径不对的、启动时间异常的才是真正要盯的对象。我一般会先落一份结构化快照而不是靠眼睛扫# 生成当前进程快照按可执行文件路径排序便于和基线 diff ps -eo pid,ppid,user,lstart,cmd --sortcmd /tmp/ps_now.txt # 只看监听端口和对应进程排除本地回环 ss -tulnp | grep -v 127.0.0.1 /tmp/port_now.txt # 和基线对比只输出新增行 diff /opt/baseline/ps_base.txt /tmp/ps_now.txt | grep ^-eo指定输出字段lstart给出精确启动时间攻击者重启过的进程时间戳往往和系统启动时间对不上--sortcmd让输出顺序稳定diff 才有意义ss -tulnp里-t-u分别是 TCP/UDP-l只看监听-n不做域名解析避免卡顿-p带进程信息。diff 结果里开头的是当前多出来的行逐条确认路径。如果发现进程的可执行文件在/tmp、/dev/shm这类目录下基本可以直接判定异常先记录 PID 和完整路径再kill -9别急着删文件——文档里“先保护现场”的原则在这里就适用。2.2 系统服务被替换或私装从 unit 文件找痕迹服务层面的坑更隐蔽。有人会在/etc/systemd/system/下私装一个 unit名字起得像系统自带服务systemctl status一看是 active就默认正常。巡检时要看的是 unit 文件的来源和修改时间而不是运行状态。文档把“查看系统服务比对有无异常发现可疑服务登记其位置”列为独立步骤位置二字很关键。# 列出所有已启用服务及其 unit 文件路径 systemctl list-unit-files --stateenabled # 找出最近 30 天内被修改过的 unit 文件 find /etc/systemd/system /usr/lib/systemd/system -name *.service -mtime -30 -ls第一条命令的--stateenabled只列开机自启的攻击者要持久化通常会把服务设成 enabled第二条用-mtime -30筛最近改动正常系统服务的 unit 文件很少变动近期被改过的大概率有问题。发现可疑服务后先systemctl stop 服务名停止运行再systemctl disable 服务名取消自启把 unit 文件路径和内容登记到巡检表后续再决定是删除还是取证。这里有个血泪经验别在业务高峰期直接disable有些看似可疑的服务其实是某个监控 agent 的依赖停之前先systemctl list-dependencies 服务名看一眼反向依赖。3. 账户和权限被动手脚可疑用户、提权与登录痕迹3.1 UID 为 0 的“第二个 root”怎么揪出来账户巡检最容易漏的是 UID 为 0 的非 root 用户。攻击者拿到权限后常干的一件事就是加一个 UID 0 的账户这样whoami显示的不是 root但实际拥有 root 权限很多只看用户名的巡检直接放过。文档要求“查看系统用户账户、密码发现可疑用户立即登记并禁用”落地时得把判断条件写死。# 找出所有 UID 为 0 的账户正常只应有 root 一行 awk -F: $30 {print $1, $3, $7} /etc/passwd # 列出可登录 shell 的账户排除 nologin/false awk -F: $7 !~ /(nologin|false|sync|shutdown|halt)$/ {print $1, $3, $7} /etc/passwd # 查看最近登录记录和失败尝试 last -n 20 lastb -n 20 2/dev/nullawk -F:以冒号分隔解析/etc/passwd$30筛 UID 为 0$7是登录 shell。第二条把 shell 为nologin、false等不可登录的账户排除剩下的就是真正能登进来的账户逐个核对是否业务需要。last看成功登录lastb看失败尝试需要 root 读/var/log/btmp。发现可疑账户后正确顺序是先usermod -L 用户名锁定再passwd -l 用户名锁密码然后gpasswd -d 用户名 组名清理其所在的特权组最后查~/.ssh/authorized_keys里有没有被塞公钥。文档里“查看其登陆痕迹用户组中清理其权限”说的就是这个顺序先断入口再清权限别反过来。3.2 sudo 权限和 SSH 公钥两个常被忽略的提权入口账户本身没问题不代表权限没被改。/etc/sudoers和/etc/sudoers.d/下多一行用户名 ALL(ALL) NOPASSWD: ALL就等于给了免密 root。巡检时用visudo -c校验语法再逐个看sudoers.d下的文件。SSH 公钥同理authorized_keys里多一把陌生公钥攻击者随时能免密回来。# 校验 sudoers 语法并列出所有授权规则 visudo -c grep -rE NOPASSWD|ALL\(ALL /etc/sudoers /etc/sudoers.d/ 2/dev/null # 找出所有用户的 authorized_keys 及其修改时间 find /home /root -name authorized_keys -exec ls -l {} \;visudo -c只做语法检查不会改文件安全grep -rE递归搜NOPASSWD和ALL(ALL这类高危授权输出里每一行都要能对应到已知的运维需求。find ... -exec ls -l把公钥文件的修改时间带出来近期被改过的重点看。处理原则和账户一致先注释掉可疑行或移走公钥文件备份到巡检取证目录再验证业务不受影响最后才删除。4. 防火墙、日志和备份三个“以为在跑其实没跑”的检查点4.1 防火墙开着但规则被清空systemctl status firewalld显示 active不代表规则还在。有人为了排查连通性临时--add-port或直接--panic-off事后忘了恢复防火墙进程活着但形同虚设。文档把“检查防火墙是否开启例外列表异常”单列重点在例外列表。巡检时要看的是规则数量和默认策略而不是服务状态。# 查看防火墙默认策略和规则数量 firewall-cmd --state firewall-cmd --list-all firewall-cmd --list-all-zones | grep -c rule # 若用 iptables直接看规则链和默认策略 iptables -L -n --line-numbers | head -40--list-all输出当前默认 zone 的服务、端口、富规则重点看target是不是default或DROP以及ports里有没有不该开放的端口。--list-all-zones | grep -c rule统计富规则条数和基线比数量骤降就要警惕。iptables 场景下-L -n不做解析、--line-numbers带行号方便定位。发现规则被清先别急着重启防火墙服务重启可能把现有连接全断正确做法是按基线快照逐条补回规则补完再--reload验证。4.2 安全日志被清空或轮转异常日志巡检的坑在于“有文件”不等于“有内容”。攻击者常干的是echo /var/log/secure或者删掉再建空文件文件在、权限对但历史记录没了。文档要求“检查系统日志关注安全日志可以备份后下载至本地进行分析”备份这个动作本身就是发现异常的手段——如果备份时发现日志比上次巡检还短就是信号。# 查看关键安全日志的大小和最后修改时间 ls -l /var/log/secure /var/log/auth.log /var/log/messages 2/dev/null # 统计近 24 小时失败登录次数异常高说明在被爆破 grep -c Failed password /var/log/secure 2/dev/null || \ journalctl --since 24 hours ago | grep -c Failed password # 检查日志服务自身是否正常 systemctl status rsyslog --no-pager | head -5ls -l看大小和 mtime和基线记录对比grep -c统计失败登录次数单日几百次以上基本是在被扫journalctl --since是 systemd 系统上rsyslog缺失时的替代路径。systemctl status rsyslog确认日志服务没被停。发现日志被清第一反应不是骂人而是立刻把当前所有日志打包备份到离线位置再查history、/root/.bash_history和登录记录还原时间线。4.3 备份任务“成功”但备份文件是空的备份巡检最典型的翻车定时任务返回 0日志写“backup completed”实际备份文件 0 字节或者只备了个空目录。文档把“检查备份任务执行情况及时纠正错误的任务”列为独立项纠正二字说明光看任务状态不够得验证产物。# 查看备份目录下文件大小和最新修改时间 find /backup -type f -mtime -1 -exec ls -lh {} \; | sort -k5 -h # 检查定时任务最近执行记录 grep -i backup /var/log/cron 2/dev/null | tail -20 journalctl -u cron --since 24 hours ago --no-pager | tail -20find -mtime -1筛 24 小时内修改的文件-exec ls -lh带出人类可读大小sort -k5 -h按大小排序一眼看出哪个备份文件异常小。grep -i backup /var/log/cron看任务是否真的执行了journalctl -u cron是 systemd 系统的对应路径。发现空备份先手动跑一次备份脚本看报错常见原因是磁盘满、目标路径权限变更、数据库导出命令参数写错。修好后别只跑一次就算完连续观察三个周期确认稳定。5. 巡检避坑五条踩出来的经验5.1 没有基线快照巡检等于白做现象巡检表填得满满当当真出问题时拿不出“正常长什么样”的对照。原因文档强调“上线前做好一份系统状态的镜像”很多人跳过这步直接开始日常巡检。解决新服务器交付当天把进程、端口、服务、账户、防火墙规则、关键目录权限各导出一份存到离线位置命名带日期之后每次巡检先 diff 再判断。5.2 只查不记异常跟踪断链现象巡检时发现可疑进程随手 kill 了过两周同样的问题又出现查不到上次的处理记录。原因文档“异常管理和跟踪”要求先保护现场、留证据实际执行时图快直接处理。解决巡检表里“原纪录”和“检查情况”两栏必须填可疑对象的路径、PID、发现时间、处理动作写清楚处理前先cp一份到取证目录。5.3 磁盘权限和上传目录被忽略现象Web 站点被上传 webshell回头查发现上传目录权限是 777。原因巡检清单里磁盘权限和上传目录排在最后容易被跳过。解决把find /var/www -type d -perm -ow这类命令固化进巡检脚本上传目录单独设权限、禁执行巡检时确认没有回退。5.4 补丁升级只看版本号不看重启现象内核补丁装了uname -r还是旧版本。原因补丁装完没重启或者重启失败被回滚。解决巡检时对比rpm -qa | grep kernel的已装版本和uname -r的运行版本不一致就安排重启窗口重启后再确认一次。5.5 FTP 和数据库账户权限过宽现象FTP 用户能浏览整个磁盘数据库账户是%任意主机可连。原因图省事给了最大权限巡检时没核对。解决FTP 用户限定家目录数据库账户限定来源 IP巡检时用SELECT user,host FROM mysql.user和 FTP 配置文件逐条核对发现%立即收紧。6. 快速定位把巡检从“翻文件”变成“跑脚本看差异”巡检做久了会发现真正耗时的不是判断是找。日志在哪个路径、服务 unit 在哪、备份目录多大每次现查现找一小时就没了。我的习惯是把文档里那 13 个检查点固化成一份只读巡检脚本每次跑完输出一份带时间戳的报告和上一份 diff。脚本本身不复杂关键是输出格式稳定diff 才有意义。#!/bin/bash # 只读巡检脚本输出到带日期的报告文件不做任何修改操作 REPORT/var/log/inspect/report_$(date %F).txt mkdir -p /var/log/inspect { echo 账户 UID 0 awk -F: $30 {print $1} /etc/passwd echo 监听端口 ss -tulnp | grep -v 127.0.0.1 echo 已启用服务 systemctl list-unit-files --stateenabled --no-pager echo 防火墙规则数 firewall-cmd --list-all-zones 2/dev/null | grep -c rule echo 备份文件 find /backup -type f -mtime -1 -exec ls -lh {} \; 2/dev/null } $REPORT 21 # 和上一份报告对比只看新增和消失的行 PREV$(ls -t /var/log/inspect/report_*.txt | sed -n 2p) [ -n $PREV ] diff $PREV $REPORT | grep -E ^[]脚本里每个echo对应文档巡检表的一个检查点 $REPORT 21把标准输出和错误一起落盘避免某条命令报错导致报告缺段。ls -t | sed -n 2p取第二新的报告作为对比基准diff | grep -E ^[]只输出差异行是上次有这次没有、是这次新增。跑完先看 diff差异行逐条确认没有差异再看报告里的计数类指标端口数、规则数、备份文件数是否在合理区间。几个快速定位的判断口径我一般按这张表走检查点异常信号优先动作进程可执行文件在 /tmp、/dev/shm记录路径后 kill备份文件账户UID 0 非 root、近期新增可登录账户锁定账户查 authorized_keys服务unit 文件近 30 天被改停服务、disable登记路径防火墙规则数骤降、默认策略变 ACCEPT按基线补规则不重启服务日志文件变小、mtime 异常立即离线备份查登录记录备份文件 0 字节或远小于基线手动跑脚本看报错查磁盘这套东西的价值不在脚本本身在于它把“巡检”从一次性的体力活变成了可对比、可追溯的流程。文档里那句“经验容易造成惯性思维导致故障延误”我吃过亏——有次看到熟悉的进程名直接放过后来才发现是伪装。从那以后我每次巡检都强制先跑 diff 再看报告差异行一条都不跳。希望这份巡检清单和排查思路能帮你把下一次“感觉不对”变成“有据可查”。本文还有配套的精品资源点击获取
