企业官网建设流程全解析

简介：面向运维人员与安全管理员的一份服务器安全巡检实操文档，围绕“如何把例行巡检做扎实”这一目标，系统梳理了巡检的重要性、关注点、检查内容与执行步骤，适合需要建立或规范服务器日常安全检查流程的初、中级运维从业者参考。资源包共1个文件，为docx格式的Word文档，约163KB，采用A4打印排版，可直接编辑后作为单位内部巡检制度或培训材料使用。文档内容覆盖系统服务、账户与权限、安全策略、防火墙、防病毒系统、操作系统补丁、密码安全、应用安全与磁盘权限等检查项，并给出从远程登录、进程比对、可疑账户处置到日志分析、数据库核对、备份任务验证的九步操作流程，同时附有异常管理与跟踪原则及巡检表模板，列明巡检时间、操作人员与各检查点记录字段。目前已有168人学习，可帮助读者快速搭建可落地的巡检清单与记录规范。

1. 巡检表填了三个月，为什么还是漏掉了那个可疑账户

凌晨两点被告警叫醒，登录服务器一看，/etc/passwd里多了一个 UID 为 0 的账户，名字伪装成rpcuser，而上一周的巡检表上「用户和组」那一栏明明白白写着「正常」。这不是段子，是很多团队做服务器安全巡检时的真实翻车现场：表格填得整整齐齐，异常照样从眼皮底下溜过去。问题不在人懒，而在于巡检这件事被做成了「打卡」——只看有没有填，不看比对基准是什么、异常判定标准是什么。这份《服务器安全巡检内容及方法》文档把巡检拆成用户与组、系统服务、进程、防火墙、防病毒、日志、数据库、备份、磁盘权限、上传目录、FTP 权限、补丁升级等检查点，并配了一张可打印的巡检表。它适合谁？适合手上管着几台到几十台服务器、被要求「定期出巡检记录」但又不想把巡检做成形式主义的运维和安全管理同学。下面按巡检里最容易出错的几类故障往下拆。

2. 用户和组巡检：多出来的 UID 0 账户与登录痕迹对不上

2.1 为什么「看着正常」的账户列表会骗人

账户巡检翻车的根因通常有三个。第一是没有基线：文档里强调「一台服务器上线前做好一份系统状态的镜像」，这个镜像就是比对基准，没有它，你打开/etc/passwd看到的每一个账户都「好像本来就该在」。第二是只看账户不看权限归属，可疑账户被加进了wheel或sudo组，但巡检时只扫了账户名，没扫组成员。第三是不看登录痕迹，账户建了但没登录过，和账户建了且从陌生 IP 登录过，风险等级完全不同，而巡检表上往往只有「有无异常」一个格子。

常见做法是巡检前先固化一份基线快照，之后每次巡检都做 diff，而不是凭记忆判断。基线要包含账户列表、组成员、sudoers 配置、最近登录记录四样东西，缺一样都会留下盲区。

2.2 用 diff 代替肉眼比对：账户基线快照与巡检脚本

先在上线后、确认干净的时间点打基线，存到只有 root 可读的目录：

# 建立基线目录，权限收紧，避免基线本身被篡改 install -d -m 700 /var/lib/sec-baseline # 账户与组基线 cut -d: -f1,3,4,7 /etc/passwd > /var/lib/sec-baseline/passwd.base cut -d: -f1,3,4 /etc/group > /var/lib/sec-baseline/group.base grep -vE '^\s*#|^\s*$' /etc/sudoers > /var/lib/sec-baseline/sudoers.base 2>/dev/null # 记录一次「干净状态」的登录成功记录作为参照 last -F -n 200 > /var/lib/sec-baseline/last.base

巡检时执行比对，只输出差异行：

# 账户差异：新增或删除的账户会直接体现在 diff 里 diff -u /var/lib/sec-baseline/passwd.base <(cut -d: -f1,3,4,7 /etc/passwd) # 组成员差异：重点看是否有人被塞进高权限组 diff -u /var/lib/sec-baseline/group.base <(cut -d: -f1,3,4 /etc/group) # 单独揪出 UID 为 0 的非 root 账户，这是最高优先级信号 awk -F: '$3==0 && $1!="root" {print "可疑UID0账户:", $1}' /etc/passwd

逻辑说明：cut只取账户名、UID、GID、登录 shell 四个字段，去掉密码占位符和注释噪音，让 diff 结果干净可读；diff -u的+行是新增、-行是删除，新增账户必须逐个确认来源。参数上，-F让last输出完整时间戳，方便和变更记录对时间线；-n 200限制条数避免输出过长。最后那条awk是兜底检查，因为有些后门账户会直接复制 root 的 UID，diff 里看起来只是「多了一行」，但 UID 0 这个特征一抓一个准。

发现可疑账户后的处置顺序，文档给的原则是先保护现场再动手：先last -F | grep 账户名和grep 账户名 /var/log/secure（Debian 系是/var/log/auth.log）把登录痕迹导出留存，再usermod -L锁定、usermod -s /sbin/nologin禁用登录，最后从高权限组里移除。顺序反了，痕迹可能被清理，事后说不清影响范围。

2.3 登录痕迹与密码策略的交叉验证

账户列表干净不代表没问题。巡检时还要看两件事：一是lastb里失败登录的集中来源，短时间内大量失败往往意味着在试密码；二是密码策略是否被改松，/etc/login.defs里的PASS_MAX_DAYS、PASS_MIN_LEN和 PAM 的pam_pwquality配置是否还符合要求。文档把「用户密码安全」列为巡检内容之一，落地时就是查这几个文件有没有被改过，同样用基线 diff 的方式比对，比每次重新读一遍配置可靠得多。

3. 进程与服务巡检：可疑进程结束不掉、服务停了又自己起来

3.1 进程「杀了又活」的根因在哪

巡检时发现可疑进程，kill -9之后过几分钟又出现，这是最让人头皮发麻的场景之一。根因通常不在进程本身，而在它的父级：要么是 systemd 服务带Restart=always，要么是 crontab 里有一条定时拉起，要么是父进程 fork 出子进程、你只杀了子进程。文档的巡检步骤里写的是「发现可疑进程登记并结束进程」，但实操中「登记」这一步必须包含父进程 PID、可执行文件路径、监听端口三样信息，否则结束进程只是治标。

另一个常见坑是只看ps aux的进程名。恶意进程会把名字伪装成[kworker/0:1]这类内核线程样式，方括号开头在ps输出里很容易被当成内核线程跳过。判断方法很简单：内核线程的 PID 通常很小且父进程是 2（kthreadd），用户态进程伪装不了这一点。

3.2 定位可疑进程的完整链路：从端口反查到文件

我一般的排查顺序是从外到内：先看监听端口，再反查进程，最后落到文件。这样不容易被进程名误导。

# 1. 列出所有监听端口及对应进程，陌生端口优先关注 ss -tulnp | sort -k5 # 2. 对可疑 PID 查完整信息：父进程、启动命令、可执行文件真实路径 pid=12345 ps -o pid,ppid,user,lstart,cmd -p "$pid" readlink -f /proc/$pid/exe ls -l /proc/$pid/cwd # 3. 查它被谁拉起：父进程链和定时任务 ps -o pid,ppid,cmd -p "$(ps -o ppid= -p $pid | tr -d ' ')" crontab -l; ls -l /etc/cron.*/ /var/spool/cron/ 2>/dev/null # 4. 确认是 systemd 托管服务时，看它的重启策略 systemctl status <服务名> --no-pager systemctl cat <服务名> | grep -i restart

逻辑说明：ss -tulnp的-p需要 root 才能看到进程归属，普通用户跑出来进程列是空的，这是新手最常问的「为什么看不到进程」；readlink -f /proc/$pid/exe拿到的是可执行文件的真实路径，即使进程名被改也能定位到二进制位置，路径落在/tmp、/dev/shm、/var/tmp这三个目录的基本可以直接判定为高危。systemctl cat比status更有用，因为它把 unit 文件原文打出来，Restart=always这类配置一眼可见。如果确认是 systemd 服务在反复拉起，处置顺序是先systemctl stop再systemctl disable，最后才删文件，直接删二进制会导致服务进入 failed 状态反复重试，日志被刷爆。

3.3 服务基线：把「应该运行的服务」列成白名单

服务巡检的难点和账户一样：没有白名单就没有异常。文档要求「查看系统服务，比对有无异常」，落地做法是维护一份应运行服务清单，巡检时做集合差：

# 导出当前处于 running 状态的服务名 systemctl list-units --type=service --state=running --no-legend | awk '{print $1}' | sort > /tmp/svc.now # 与白名单比对，输出多出来的服务 comm -13 /var/lib/sec-baseline/svc.allow /tmp/svc.now

comm -13的含义是只输出「第二个文件有、第一个文件没有」的行，也就是当前在跑但白名单里没有的服务。白名单文件一行一个服务名，首次建立时人工确认一遍，之后每次巡检只看差集。这个方法的成本很低，但能抓住绝大多数「悄悄装了个服务」的情况。对于 Windows 服务器，对应做法是用Get-Service | Where-Object {$_.Status -eq 'Running'}导出运行中服务列表，同样和白名单比对，思路完全一致。

4. 防火墙、防病毒与日志巡检：规则被改、日志被清、备份静默失败

4.1 防火墙例外列表被悄悄加了一条

防火墙巡检最常见的翻车是「防火墙是开着的，但例外列表里多了一条放行全部来源的规则」。只检查服务是否运行（systemctl status firewalld显示 active）完全不够，必须把规则本身纳入基线。文档把「检查防火墙是否开启，例外列表异常」单列一条，说明编写者踩过这个坑。

# 导出当前规则做基线，之后每次巡检 diff firewall-cmd --list-all > /var/lib/sec-baseline/fw.base 2>/dev/null # 巡检时比对 diff -u /var/lib/sec-baseline/fw.base <(firewall-cmd --list-all)

用 iptables 的环境对应iptables-save > 基线文件，巡检时iptables-save | diff 基线文件 -。重点看ports、sources、rich rules三段，任何新增的0.0.0.0/0放行都要有变更单对应，对不上就是异常。

4.2 防病毒与补丁：更新停了比没装更危险

防病毒系统巡检要看三样：进程在不在、病毒库版本日期、有没有被篡改的痕迹。库版本超过一周没更新，基本可以判定更新通道断了，这时候「防病毒在运行」是个假象。补丁巡检同理，重点不是「装没装补丁」，而是「补丁源还通不通、最近一次成功更新是什么时候」。常见做法是记录每次巡检时的库版本号和补丁列表，形成时间序列，一旦某次巡检发现版本号和上次完全一样，就要去查更新服务本身。

4.3 日志与备份：静默失败最坑人

日志巡检的要点是「安全日志备份后下载到本地分析」，因为攻击者拿到权限后第一件事往往是清日志。巡检时先看日志文件大小和最后修改时间是否合理，再看有没有logrotate之外的截断痕迹。备份巡检则是文档里最容易被跳过的一项——「检查备份任务执行情况，及时纠正错误的任务」。备份失败往往是静默的：任务返回 0 但实际没写出文件，或者写到了满盘的目录。巡检时不能只看任务状态，要验证备份产物：

# 检查最近一次备份文件是否存在、大小是否合理、时间是否是预期周期内 find /backup -type f -mtime -1 -size +10M -printf '%TY-%Tm-%Td %TH:%TM %s %p\n' | sort | tail -5

-mtime -1限定 24 小时内修改过的文件，-size +10M过滤掉空文件和日志碎片，-printf输出时间、大小、路径三列。如果这条命令没有任何输出，说明 24 小时内没有产生合格备份，无论备份任务界面显示什么状态，都按失败处理。这个检查我一般会写进巡检脚本固定执行，因为「备份看起来在跑」和「备份真的能用」之间隔着无数次翻车。

5. 避坑清单：巡检表上那些「填了等于没填」的格子

5.1 现象：巡检表全勾「正常」，出事回溯发现异常早就在

原因：巡检项没有判定标准，只有「正常/异常」两个选项，执行人凭感觉勾。解决：每个巡检项后面补一列「参考标准」，比如用户项的标准是「与基线 diff 无新增」，服务项的标准是「与白名单差集为空」，把主观判断变成客观比对。文档的巡检表里本来就有「参考标准」和「原纪录」两列，很多人打印时把这两列省了，等于把表废了一半。

5.2 现象：可疑进程结束不掉，或者结束后系统出现异常

原因：只杀了子进程没处理父进程，或者误杀了伪装成可疑进程的正常业务进程。解决：结束前必须记录ppid、exe真实路径、监听端口三要素，确认父进程来源后再动手；对拿不准的进程先systemctl stop对应服务而不是直接kill -9，保留现场供后续分析。

5.3 现象：磁盘权限和上传目录巡检被跳过，因为「不知道看什么」

原因：这两项没有明确的检查命令，执行人不知道从哪下手。解决：磁盘权限重点看敏感目录的属主和权限位，find /var/www -perm -o+w -type d找出所有人可写的目录，上传目录重点看有没有可执行权限的文件，find 上传目录 -type f \( -name '*.php' -o -name '*.jsp' -o -name '*.sh' \)一条命令就能筛出来。上传目录里出现脚本文件，基本就是被传了后门。

5.4 现象：巡检做了，但没有任何记录，事后无法证明做过

原因：巡检结果只存在执行人脑子里或临时终端里。解决：每次巡检的输出统一重定向到带日期的文件，脚本 >> /var/log/sec-inspect/$(date +%F).log，巡检表填写时引用该日志。文档强调「做好记录和分析笔记」，记录的价值不在于应付检查，而在于下次出问题时能回答「上次巡检时这个值是多少」。

5.5 现象：换了新服务器，巡检照旧做，但基线是旧的

原因：基线快照没有随服务器重建而更新，拿旧基线比新机器，diff 全是噪音，执行人干脆不看 diff 了。解决：把「重建基线」写进服务器上线流程，新机器交付当天打基线并记录基线生成时间，巡检脚本启动时先校验基线文件的存在时间和主机名是否匹配，不匹配直接报错退出，避免拿错基准做无效比对。

6. 快速定位：把巡检从「翻表格」变成「看差集」

巡检出问题时，最快的定位路径不是从头翻一遍所有检查项，而是先回答一个问题：这次异常是「新增」还是「变化」？新增看差集，变化看基线 diff，两条路走完，八成的问题已经浮出水面。我习惯的固定顺序是：先跑账户和服务的差集（最快、信号最强），再看防火墙规则 diff，然后查进程的端口与文件路径，最后才去翻日志。日志量大、噪音多，放在最后看，而且只看和前面几步时间点吻合的片段，不做全文通读。

下面这张对照表是我把文档里的巡检项和对应的快速判定命令整理在一起的版本，巡检时按行执行，输出为空即该项通过：

验证巡检脚本本身是否可靠，也有个简单办法：故意在测试机上建一个测试账户、开一个测试端口，跑一遍巡检脚本，看能不能报出来。报不出来，说明脚本的比对逻辑有问题，先修脚本再谈巡检。这个「自测」步骤很多人省了，结果脚本静默失效几个月都没人发现，比不巡检还危险。

从那以后我每次接手新服务器，第一件事不是装监控，而是先打基线、写巡检脚本、然后拿测试账户和测试端口把脚本验一遍，三件事做完才认为这台机器「进入可巡检状态」。巡检的价值不在于表格填得多漂亮，而在于异常出现时你能在一分钟内说出「它和基线差在哪」。这份文档把巡检项和巡检表都列全了，照着把每一项落成一条可比对的命令，巡检才算真正跑起来。希望帮到你。

本文还有配套的精品资源，点击获取