尧图网站建设 
简介网络安全加固服务方案是一份面向网络安全工程师、解决方案架构师及等保合规人员的原创服务方案模板可直接用于编写项目实施方案、投标技术文件或等保整改报告。压缩包内为单个docx文档约99KB虽体量不大但框架完整覆盖安全加固基本概念、服务必要性、客户收益、服务实施标准与六项服务原则等前置章节。文档将加固范围拆解为网络设备、主机操作系统、数据库、常见中间件及网络服务等模块并细化各模块的加固动作如补丁管理、弱口令整改、配置基线核查、账号权限收敛等同时参考GB/T 22239等级保护等标准确保方案符合合规要求。目前已有145人浏览学习适合需要快速输出专业安全方案、提升交付文本质量的从业者替换关键词即可直接复用。1. 网络安全加固服务方案为什么经常沦为一纸报告做了几年安全服务交付我最大的感受是「网络安全加固」这几个字甲方和乙方理解得完全不一样。甲方以为加固就是漏扫加补漏洞乙方拿着服务方案进场却常常发现加固动作还没开始业务方已经在催验收。去年一个客户更是让我记忆深刻方案里写着「全面整改弱口令」实施团队把生产库的 root 密码一改业务侧所有连接串全部失效连接池当场爆掉。这不怪工具怪方案只写了目标和清单没写顺序、边界和回滚。这篇就把带加固项目时的实际做法摊开讲方案先盘清什么基线怎么选主机和中间件上哪些改动易翻车出了问题怎么退最后拿什么证明加固有效。适合刚独立带加固实施的安全工程师也适合要给客户交付安全服务、被等保和验收追着赶进度的项目负责人。你手头那份网络安全加固服务方案.docx与其当模板抄不如按下面的路径改成施工图。2. 写加固方案前先盘清家底和基线这两个地基2.1 资产盘点清单主机、端口、账号一次抄清常见做法是所有加固服务都会安排现场调研但很多方案把调研做成了「收集表格」。客户填回来的资产表经常是半年前的漏掉一堆测试机和临时开的端口。我一般会保留客户填的表然后自己再做一遍技术核查两边数据对不上时以技术核查为准。一个最小可用的技术核查清单长这样主机名与 IP管理 IP 和业务 IP 分开写、操作系统版本、开放端口及对应进程、登录账号和 sudo 权限、中间件版本和端口、数据库实例和监听地址、启动方式systemd、cron 还是手工。如果客户环境里已有漏扫报告就把扫描结果按 IP 归并拿每个 IP 的开放端口清单去跟业务侧确认「这个端口还有没有人在用」。这一步我通常用 nmap 做快速摸底nmap -sS -sV -p- -T4 --open -oX inventory.xml -iL ips.txt逻辑说明-sS是半开扫描需要 root 权限速度比全连接快对目标产生的日志也少-sV做服务版本识别后面判断中间件版本、找已知 CVE 时依赖它-p-扫全端口很多加固项目翻车就翻在只扫了常见端口漏了 8000 往上的管理端口-oX输出 XML方便后续脚本解析-T4是对时序的调节扫描几百台机器建议拆成几个网段并行跑同时把发包速率往下压一压避免把老设备扫挂。注意一点任何扫描都要先拿到客户书面授权扫描前跟客户确认窗口别在业务高峰跑全端口。拿到端口清单后逐项标注「业务必开」「管理专用」「疑似废弃」后面做防火墙策略收敛时直接依据这张表来。账号盘点这块最容易漏的是服务账号和历史遗留账号。我会用一条脚本把本机账号和登录状态拉出来# 拉取本机账号与口令状态标记可登录账号 awk -F: {print $1, $3, $7} /etc/passwd | while read user uid shell; do if [ $uid -ge 1000 ] || [ $shell ! /sbin/nologin ]; then passwd -S $user 2/dev/null fi done参数说明/etc/passwd里按冒号分割第二列是 UID第七列是登录 shell。我们筛掉 UID 小于 1000 且 shell 为/sbin/nologin的系统账号只对疑似可登录账号查口令状态。输出里的PS、LK、NP分别表示密码正常、已锁定、无密码。无密码的账号是加固清单里的头号目标优先处置。2.2 加固基线怎么选等保基线、CIS 还是厂商手册基线选型直接决定方案体量。市面常见做法是三种等保测评基线、CIS Benchmark、设备厂商出厂安全配置手册。三者不是互斥关系而是分层关系。等保二级/三级基线是大多数政企客户验收的底线覆盖身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范这些维度条款颗粒度比较粗比如「应重命名或删除默认账户」但不会告诉你具体删哪个。CIS Benchmark 颗粒度细得多Linux、MySQL、Nginx 都有对应的 benchmark每条配了预期值和检测命令适合做实施层的执行依据。厂商安全手册则更贴近设备本身的可用性比如交换机和防火墙的加固手册会写明哪些协议建议关闭、哪些端口建议限制源地址。我做方案时的习惯是以等保基线作为验收框架把 CIS 的条目当成执行清单再用厂商手册做兜底修正。三层合在一起给客户的方案里明确写出「每条加固项的来源是哪个文件、预期值是什么、检测命令是什么」。比如同样一个 SSH 加固项等保只写「应采用两种或两种以上身份鉴别技术」CIS 会细分到PermitRootLogin、MaxAuthTries、ClientAliveInterval这些参数。落地时直接抄 CIS 的参数表验收时拿等保条款去对照效率最高。基线冲突的典型场景也要在方案里提前讲清楚。等保要求日志留存六个月而磁盘只够存两周CIS 要求 SSH 禁止 root 登录客户的老运维脚本却全在用 root 直连。这类冲突方案里要给出取舍建议和例外申请流程千万别在实施现场临时拍板。还有一类是基线核查工具本身的选择预算有限的客户没必要一上来就买商业漏扫可以先拿 OpenSCAP 或 lynis 做免费基线核查规则透明、能改模板适合固定场景反复跑商业漏扫的优势集中在资产发现和漏洞关联自己团队用得熟之后再引入也不迟。2.3 实施顺序和回滚预案方案里最薄的两页纸方案里写得最薄、实施时最救命的是顺序和回滚。我一般按「网络设备 → 主机系统 → 中间件 → 数据库」的顺序推每推一层做一次业务抽验验证通过再动下一层。原因很简单网络层把不合规的访问先断掉后面主机和应用的改动即使慢半拍风险面已经被收住了数据库放到最后是不希望口令变更这类操作影响业务高峰期。每一类改动在实施前必须留下回滚手段这是方案里的强制项。配置文件先备份备份文件名带日期防火墙规则变更前先导出一份当前规则SSH 配置修改前保持一个已登录的会话窗口不要关。这些都是血泪经验改sshd_config时如果同时改了端口和防火墙一旦配置写错当前连接一断就再也进不去了唯一的后悔药就是让现场同事从带外管理口进来救。配合顺序我还会在方案里附一张回滚决策表写清楚什么情况回滚、回滚到什么状态、由谁发起回滚。比如「SSH 配置导致无法登录」对应「恢复sshd_config.bak并 reload」「数据库口令修改导致应用连接失败」对应「登录数据库改回原口令并刷新连接池」。回滚决策表不需要写多深但必须写明责任人和操作入口避免现场几个人围着一台机器争论半天。实际项目里这张表比任何加固说明都常被翻看。3. 把加固条目落到主机和中间件可抄作业的配置与命令3.1 账号口令与权限收敛从空口令到 sudo 白名单账号口令是每次加固实施最先开刀的地方也是最容易误伤的地方。先处理空口令和弱口令再做权限收敛。检查空口令和可登录账号的状态# 检测空口令账号RHEL/CentOS 系 awk -F: ($2 || $2 !!) {print $1} /etc/shadow逻辑说明/etc/shadow第二字段是加密口令空字符串表示未设置密码!!表示该账号从未设置过口令或已被锁定。输出了用户名后逐个处置确认不再使用的账号直接passwd -l还在用的账号立刻设置强口令。这里有个细节某些系统对锁定账号显示的是!而不是!!所以判断时最好把$2 !、$2 !!都算进去。密码复杂度策略放在/etc/login.defs和/etc/pam.d/system-auth两个地方。前者控制全局密码长度和时效# /etc/login.defs 关键参数 PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 9 PASS_WARN_AGE 14参数说明PASS_MAX_DAYS 90是 90 天强制改密PASS_MIN_DAYS 7防止改完马上又改回去配合历史记录才能拦住重复使用旧密码PASS_MIN_LEN 9设最小长度PASS_WARN_AGE 14提前两周提醒。注意PASS_MIN_LEN只对passwd命令的交互式修改生效不约束 root也不约束通过 SSH 密钥登录的账号所以它只是第一道门槛。真正限制弱口令要靠 PAM 的pam_pwquality模块里面可以设minlen、dcredit、ucredit这些复杂度参数。权限收敛的重点是 sudo 白名单和 UID 0 账号。先查 UID 0 的账号正常情况下应该只有 root# 列出 UID 0 账号和 sudo 组成员 awk -F: $3 0 {print} /etc/passwd getent group wheel如果发现第二个 UID 0 账号基本可以判定是后门要跟客户确认后立即删除。sudo 权限则按最小化原则收敛把客户现场管理员账号加入 wheel 组普通运维账号从 sudoers 里删掉。常见翻车点是某个应用账号在 sudoers 里配了ALL(ALL) ALL这类条目要收紧到「只允许执行指定命令」比如只允许systemctl restart nginx、tail -f /var/log/nginx/access.log。还有一个很多人忽略的点历史遗留的.rhosts、/etc/hosts.equiv这类 r 系列协议残留一旦开着等于给本机开了个后门。加固时直接确认这些文件不存在并把rexec、rlogin、rsh对应的服务端口检查一遍。3.2 SSH 加固改端口、禁 root 登录与密钥登录的先后顺序SSH 加固是翻车重灾区但不是因为配置复杂而是操作顺序不对。常见做法是先备份、再改配置、最后 reload 验证顺序不能反。# 备份并查看 sshd_config 当前关键项 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) grep -E ^(#)?(Port|PermitRootLogin|PasswordAuthentication|MaxAuthTries|AllowUsers) \ /etc/ssh/sshd_config先用 grep 把当前值拉出来看一眼再动手修改。改法推荐直接编辑文件而不是 sed 一把梭因为不同发行版默认配置差异很大sed 处理注释行容易出现重复项。以 RHEL/CentOS 为例一组常用的加固值Port 2222 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes MaxAuthTries 3 LoginGraceTime 30 AllowUsers ops monitor参数说明Port 2222避开默认端口但要注意和防火墙同步改PermitRootLogin no禁止 root 直连运维人员用普通账号登录后再su -PasswordAuthentication no关闭密码登录前提是已经把运维公钥写进~/.ssh/authorized_keys否则改完你就是被自己关在门外的人MaxAuthTries 3限制登录尝试次数配合LoginGraceTime 30缩短单次登录的窗口能挡掉一部分暴力破解。AllowUsers是最后一道闸把 SSH 可登录账号收敛到极少几个。这里有个特别重要的顺序先把公钥部署好、用新端口测试能登录再关闭密码认证最后再禁 root。公钥部署可以用ssh-copy-id完成部署后用第二个会话验证「密钥登录 新端口」链路是通的再动配置。否则一旦公钥权限不对或者端口被防火墙挡了你只能去机房。还有一个容易忽略的参数是ClientAliveInterval和ClientAliveCountMax。默认配置下空闲 SSH 连接可能挂一整天既占会话资源又扩大了被利用面。一般设ClientAliveInterval 300和ClientAliveCountMax 2表示 5 分钟没动静就发心跳探测连续两次无响应就断开。这个值对长任务有影响跑着后台任务的会话最好配合 tmux 或 nohup别让连接被服务端踢掉导致任务中断。验证 SSH 加固是否生效不要只看配置文件要看实际监听结果ss -tlnp | grep sshdss输出里如果监听端口已经是 2222且旧端口没有进程在监听才算配置真正生效。改完别忘执行systemctl reload sshd注意是 reload 不是 restartrestart 会短暂断开现有连接reload 则平滑生效。3.3 中间件与数据库加固Tomcat、Nginx、MySQL 的常见动作中间件加固和系统加固的差别在于中间件出了问题直接影响业务请求所以每改一个参数都要想清楚「这个参数背后是哪个业务路径」。以最常见的 Nginx、Tomcat、MySQL 为例。Nginx 的第一件事是隐藏版本号并清理不用的入口# nginx.conf 关键配置 server_tokens off;server_tokens off让响应头不再带nginx/1.20.1这类版本信息攻击者少了精确版本号找对应 CVE 的成本就高了。配套动作是检查默认 server 块把不用的location和alias路径清理掉特别是那些指向/etc/、/var/log/的别名路径曾经出过不少文件读取漏洞。Tomcat 的重点是管理端和自动部署。Tomcat 自带的manager、host-manager是渗透测试最喜欢的入口业务用不到就直接在tomcat-users.xml里注释掉对应角色并删除webapps/下的相关目录。server.xml里的autoDeploy也要关# 关闭 Tomcat 自动部署避免上传 JSP 后即时生效 sed -i s/autoDeploytrue/autoDeployfalse/ server.xml参数说明autoDeploy是热部署开关等于 true 时攻击者只要上传一个 JSP webshell 到webapps目录就会被自动加载执行这是 Tomcat 被拿下的常见路径。关掉之后部署新应用需要手工 reload运维会多一些操作但安全性提升明显。还要顺手确认disableUploadTimeout和请求体大小限制防止通过大请求体绕过 WAF 的检测。MySQL 加固的项目不多但每一条都可能踩雷。先跑官方自带的mysql_secure_installation处理匿名账号和测试库。需要额外注意的是MySQL 8 默认认证插件是caching_sha2_password如果应用连接串用的是老驱动改完认证方式可能导致连不上。另一个常见动作是关闭LOCAL INFILE和限制日志-- MySQL 安全相关参数 SET GLOBAL local_infile OFF; SET GLOBAL general_log OFF;参数说明local_infile控制是否允许通过LOAD DATA LOCAL INFILE读取客户端本地文件曾是被利用来读服务器敏感文件的入口之一关闭后对绝大多数业务无感知但如果有应用确实依赖本地文件导入必须在方案例外清单里写明并加白名单控制。general_log打开时会记录所有 SQL日志量极大且含敏感数据正常业务下保持关闭需要排查问题时再短时打开。数据库口令这一项要特别谨慎改口令前先查应用配置里用的是哪个账号连接串是明文还是加密改完口令后连接池是否会自动感知。稳妥做法是在低峰期改口令改完立刻触发一次应用重连测试不要等到第二天业务高峰再验证。很多项目就是改密码这一步没做全链路测试第二天早上应用全部报Access denied才回头来找我们。3.4 日志和审计加固完能回溯攻击路径才算闭环加固的最后一环是日志没有日志的加固等于白做出事之后你根本说不清楚攻击者是从哪条链路进来的。系统层面我一般开两样auditd的审计规则和远程日志转发。auditd的规则可以精确到文件级别# 审计 passwd、shadow、sudoers 等关键文件的写操作 auditctl -w /etc/passwd -p wa -k identity auditctl -w /etc/shadow -p wa -k identity auditctl -w /etc/sudoers -p wa -k privilege参数说明-w指定监控文件-p wa表示记录写和属性变更-k是打标签后续用ausearch -k identity可以快速过滤出这一类事件。规则要写成/etc/audit/rules.d/下的文件并执行augenrules --load否则重启后规则丢失只对当前内核生效。远程日志转发是配套动作把/var/log/secure、/var/log/messages、审计日志统一送到日志服务器# /etc/rsyslog.d/security.conf authpriv.* 192.0.2.10:5514 *.info;authpriv.none 192.0.2.10:5514参数说明authpriv.*是认证类事件远程收日志后本机即使被清理了痕迹日志服务器上还有一份。表示 UDP表示 TCP日志量大且要求可靠传输时用 TCP。日志服务器要单独划一个网段别让生产网段的任意主机都能访问 5514 端口否则日志服务器本身就是个巨大攻击面。日志这块要留意的是格式和时区。多台服务器如果 NTP 没对齐日志时间差出去几十秒事后溯源就对不上攻击时间线。加固方案里要把 NTP 对齐列为一个独立检查项实施完日志集中采集后挑三条测试日志确认时间戳一致。日志留存周期也要在方案里写清楚至少覆盖等保要求的期限超出磁盘容量就旋转归档别把日志目录撑爆导致应用写不了日志。4. 加固排障避坑业务没崩不算完隔天失效更要命4.1 重启后配置被覆盖初始化脚本、配置管理平台在打架现象加固完成后第三天客户反映服务器重启了一次再登进去发现/etc/ssh/sshd_config和密码策略全部回到加固前的样子等于白干。原因云主机上有初始化脚本每次启动会把一套默认配置写回去或者客户的配置管理平台定时从配置库拉取并下发配置把人工改动覆盖掉了。这两种情况在政企环境里非常常见。解决先确认这台机器是否被配置管理平台纳管如果有应先调整配置库里的基线而不是只改单机。有些客户会坚持先只改单机这时对配置文件加锁可以挡一阵# 对关键配置文件加不可变属性 chattr i /etc/ssh/sshd_config chattr i /etc/login.defs参数说明chattr i让文件变成不可修改连 root 也不能改所有程序写入都会报错覆盖动作自然失败。但它也是双刃剑以后任何合法修改都要先chattr -i解除忘了解锁就直接改会失败而且配置管理平台在同步时遇到只读文件会直接报错反而暴露配置漂移。所以我一般只建议对短期内无法改配置库的客户用锁同时把解锁命令写进交付文档。等客户把配置库基线更新后再统一解锁。4.2 端口关了又开防火墙规则和端口映射叠加现象实施人员用firewall-cmd封了 3306 端口外部扫描还是能扫到业务方质疑加固无效。原因要么是防火墙规则顺序不对先放行再拒绝要么目标是容器化部署容器的端口映射自带一套独立规则发布端口直接绕过宿主机防火墙还有可能是云平台安全组层面放行服务器本地防火墙根本管不着。这三种情况表现一样处置路径完全不同。解决先在目标机上确认端口到底谁在监听# 查看端口监听进程区分宿主机还是容器 ss -tlnp | grep 3306如果看到进程是docker-proxy就可以确定是端口映射放行。处置思路是优先改编排文件不让容器对外发布 3306 端口只保留容器网络内部访问如果短期内不能改编排至少要在云平台安全组层面把 3306 的入方向源地址收敛。注意不要只加本地防火墙规则就收工因为重启容器或 Docker 服务后发布规则会重新生成本地防火墙规则不一定拦得住。规则序的问题则用iptables -L -n --line-numbers检查把拒绝规则放到放行规则前面。4.3 业务登录态失效被顺手收紧的 TLS 版本和 session 存储现象加固完成后老用户登录系统频繁掉线部分老旧浏览器直接登录不上登录页报协议错误。原因排查后常见两类。一类是加固时把 TLS 1.0/1.1 协议关掉了客户内部老终端上的浏览器还停留在旧版本协议协商失败另一类是 session 存在 Redis加固时顺手改了 Redis 的监听地址或密码应用连不上 Redis 后 session 校验全部失败。解决TLS 的问题要先做兼容性评估再动。Nginx 和 Tomcat 的 TLS 版本配置改动前先统计客户端证书和终端浏览器占比必要时用中间版本过渡。Redis 这类通用存储组件在加固清单里要单独标注「影响 session/缓存的服务」变更后第一时间验证应用登录链路# 验证 Redis 连通性 redis-cli -h 127.0.0.1 -p 6379 -a $REDIS_PASSWORD ping返回PONG只代表组件层连接通还要再用应用的实际登录接口做一次全链路测试不能只看 Redis 本身。凡是动了 Redis 密码或监听地址的必须推动应用侧同步修改配置否则就是埋雷。session 失效这类问题有一个共性特征页面能打开但一登录就跳回登录页排查时先看 redis 连接日志再看应用日志里的 session 读取报错顺序不要反。4.4 生产环境翻车看着一样的环境回滚手段全不能用现象加固脚本在测试环境完整跑通拿到生产环境执行后数据库起不来回滚时发现备份文件是空的。原因测试环境和生产环境看起来版本一样细节却不同。比如数据库的数据目录权限生产环境可能被 DBA 手工改过加固脚本把数据目录权限从755收成750后MySQL 进程以mysql用户启动时读不到文件。回滚失败通常是因为备份只做了配置文件没做目录权限快照而且脚本执行时没做前置检查。解决加固脚本里每一步都要先做前置检查再执行至少包括三件事备份当前配置、记录当前目录权限、确认服务当前状态。可以写成统一的防护框架#!/bin/bash # 通用前置检查备份、记录权限、标记变更点 TS$(date %Y%m%d%H%M%S) for f in $; do cp -a $f $f.bak.$TS stat -c %n %a %U %G $f /var/log/reinforce_perms.$TS.log done echo backup completed at $TS参数说明cp -a保留属主、属组和权限备份的不是普通副本stat输出权限和属主写入日志回滚时可以直接按日志恢复$接收传入的文件路径脚本可以复用。还应该在脚本开头检测服务状态如果服务本来就处于异常状态立刻中止别把异常环境当成健康环境加固。生产环境执行的纪律也要在方案里写明每个批次的加固范围不超过 10 台跑完一批验证一批窗口期内不做跟加固无关的变更任何一步报错立即暂停不允许跳过报错继续执行。这些纪律看着繁琐却是翻车时唯一能保障后悔药有效的机制。我的习惯是每次生产加固都安排一个人专门盯着回滚不动手操作只在报错时大喊停这个人往往是项目里资历最浅的实习生但恰恰是这双眼睛救了多数场子。5. 验收交付把加固结果做成对方能复核的证据链5.1 交付物清单逐台可复核不是一张 Excel加固做完到验收之间最忌讳只交一份「已完成 xx 项整改」的表格。客户验收需要能复核的证据链我的交付物通常分成四类逐台主机的加固实施记录、配置变更前后的 diff 文件、回滚操作手册、加固后基线快照。其中配置 diff 是核心diff -u 备份 当前配置的结果直接证明你改了什么比任何描述都有说服力。5.2 一键复核脚本与长期巡检复核基线我会做成一个脚本验收时客户按同一份脚本重新跑一遍结果一致才算闭环#!/bin/bash # 加固复核脚本输出账号、SSH、端口、关键文件状态 echo 空口令账号 awk -F: ($2 || $2 !!) {print $1} /etc/shadow echo SSH 关键参数 sshd -T | grep -E permitrootlogin|passwordauthentication echo 防火墙规则条数 iptables -L -n | wc -l脚本输出要跟交付文档里的预期值一一对应比如PermitRootLogin no、PasswordAuthentication no、防火墙规则条数不少于某个值。只输出现状、不定预期验收时还是扯皮。长期巡检方面我会把同样的复核逻辑做成每周一次的 cron 或者接入客户的巡检平台一旦发现配置漂移第一时间告警。加固从来不是一次性的动作而是一个持续对抗配置漂移的过程。做安全服务这些年我养成了习惯每次交付前把自己当成客户重新走一遍复核流程能挑出三五个问题再回去改比到验收现场被业务方指着鼻子问强得多。希望这篇拆解对你接手下一个加固项目有帮得上忙的地方。本文还有配套的精品资源点击获取 网络安全加固方案落地指南：资产、基线、回滚与验收
简介网络安全加固服务方案是一份面向网络安全工程师、解决方案架构师及等保合规人员的原创服务方案模板可直接用于编写项目实施方案、投标技术文件或等保整改报告。压缩包内为单个docx文档约99KB虽体量不大但框架完整覆盖安全加固基本概念、服务必要性、客户收益、服务实施标准与六项服务原则等前置章节。文档将加固范围拆解为网络设备、主机操作系统、数据库、常见中间件及网络服务等模块并细化各模块的加固动作如补丁管理、弱口令整改、配置基线核查、账号权限收敛等同时参考GB/T 22239等级保护等标准确保方案符合合规要求。目前已有145人浏览学习适合需要快速输出专业安全方案、提升交付文本质量的从业者替换关键词即可直接复用。1. 网络安全加固服务方案为什么经常沦为一纸报告做了几年安全服务交付我最大的感受是「网络安全加固」这几个字甲方和乙方理解得完全不一样。甲方以为加固就是漏扫加补漏洞乙方拿着服务方案进场却常常发现加固动作还没开始业务方已经在催验收。去年一个客户更是让我记忆深刻方案里写着「全面整改弱口令」实施团队把生产库的 root 密码一改业务侧所有连接串全部失效连接池当场爆掉。这不怪工具怪方案只写了目标和清单没写顺序、边界和回滚。这篇就把带加固项目时的实际做法摊开讲方案先盘清什么基线怎么选主机和中间件上哪些改动易翻车出了问题怎么退最后拿什么证明加固有效。适合刚独立带加固实施的安全工程师也适合要给客户交付安全服务、被等保和验收追着赶进度的项目负责人。你手头那份网络安全加固服务方案.docx与其当模板抄不如按下面的路径改成施工图。2. 写加固方案前先盘清家底和基线这两个地基2.1 资产盘点清单主机、端口、账号一次抄清常见做法是所有加固服务都会安排现场调研但很多方案把调研做成了「收集表格」。客户填回来的资产表经常是半年前的漏掉一堆测试机和临时开的端口。我一般会保留客户填的表然后自己再做一遍技术核查两边数据对不上时以技术核查为准。一个最小可用的技术核查清单长这样主机名与 IP管理 IP 和业务 IP 分开写、操作系统版本、开放端口及对应进程、登录账号和 sudo 权限、中间件版本和端口、数据库实例和监听地址、启动方式systemd、cron 还是手工。如果客户环境里已有漏扫报告就把扫描结果按 IP 归并拿每个 IP 的开放端口清单去跟业务侧确认「这个端口还有没有人在用」。这一步我通常用 nmap 做快速摸底nmap -sS -sV -p- -T4 --open -oX inventory.xml -iL ips.txt逻辑说明-sS是半开扫描需要 root 权限速度比全连接快对目标产生的日志也少-sV做服务版本识别后面判断中间件版本、找已知 CVE 时依赖它-p-扫全端口很多加固项目翻车就翻在只扫了常见端口漏了 8000 往上的管理端口-oX输出 XML方便后续脚本解析-T4是对时序的调节扫描几百台机器建议拆成几个网段并行跑同时把发包速率往下压一压避免把老设备扫挂。注意一点任何扫描都要先拿到客户书面授权扫描前跟客户确认窗口别在业务高峰跑全端口。拿到端口清单后逐项标注「业务必开」「管理专用」「疑似废弃」后面做防火墙策略收敛时直接依据这张表来。账号盘点这块最容易漏的是服务账号和历史遗留账号。我会用一条脚本把本机账号和登录状态拉出来# 拉取本机账号与口令状态标记可登录账号 awk -F: {print $1, $3, $7} /etc/passwd | while read user uid shell; do if [ $uid -ge 1000 ] || [ $shell ! /sbin/nologin ]; then passwd -S $user 2/dev/null fi done参数说明/etc/passwd里按冒号分割第二列是 UID第七列是登录 shell。我们筛掉 UID 小于 1000 且 shell 为/sbin/nologin的系统账号只对疑似可登录账号查口令状态。输出里的PS、LK、NP分别表示密码正常、已锁定、无密码。无密码的账号是加固清单里的头号目标优先处置。2.2 加固基线怎么选等保基线、CIS 还是厂商手册基线选型直接决定方案体量。市面常见做法是三种等保测评基线、CIS Benchmark、设备厂商出厂安全配置手册。三者不是互斥关系而是分层关系。等保二级/三级基线是大多数政企客户验收的底线覆盖身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范这些维度条款颗粒度比较粗比如「应重命名或删除默认账户」但不会告诉你具体删哪个。CIS Benchmark 颗粒度细得多Linux、MySQL、Nginx 都有对应的 benchmark每条配了预期值和检测命令适合做实施层的执行依据。厂商安全手册则更贴近设备本身的可用性比如交换机和防火墙的加固手册会写明哪些协议建议关闭、哪些端口建议限制源地址。我做方案时的习惯是以等保基线作为验收框架把 CIS 的条目当成执行清单再用厂商手册做兜底修正。三层合在一起给客户的方案里明确写出「每条加固项的来源是哪个文件、预期值是什么、检测命令是什么」。比如同样一个 SSH 加固项等保只写「应采用两种或两种以上身份鉴别技术」CIS 会细分到PermitRootLogin、MaxAuthTries、ClientAliveInterval这些参数。落地时直接抄 CIS 的参数表验收时拿等保条款去对照效率最高。基线冲突的典型场景也要在方案里提前讲清楚。等保要求日志留存六个月而磁盘只够存两周CIS 要求 SSH 禁止 root 登录客户的老运维脚本却全在用 root 直连。这类冲突方案里要给出取舍建议和例外申请流程千万别在实施现场临时拍板。还有一类是基线核查工具本身的选择预算有限的客户没必要一上来就买商业漏扫可以先拿 OpenSCAP 或 lynis 做免费基线核查规则透明、能改模板适合固定场景反复跑商业漏扫的优势集中在资产发现和漏洞关联自己团队用得熟之后再引入也不迟。2.3 实施顺序和回滚预案方案里最薄的两页纸方案里写得最薄、实施时最救命的是顺序和回滚。我一般按「网络设备 → 主机系统 → 中间件 → 数据库」的顺序推每推一层做一次业务抽验验证通过再动下一层。原因很简单网络层把不合规的访问先断掉后面主机和应用的改动即使慢半拍风险面已经被收住了数据库放到最后是不希望口令变更这类操作影响业务高峰期。每一类改动在实施前必须留下回滚手段这是方案里的强制项。配置文件先备份备份文件名带日期防火墙规则变更前先导出一份当前规则SSH 配置修改前保持一个已登录的会话窗口不要关。这些都是血泪经验改sshd_config时如果同时改了端口和防火墙一旦配置写错当前连接一断就再也进不去了唯一的后悔药就是让现场同事从带外管理口进来救。配合顺序我还会在方案里附一张回滚决策表写清楚什么情况回滚、回滚到什么状态、由谁发起回滚。比如「SSH 配置导致无法登录」对应「恢复sshd_config.bak并 reload」「数据库口令修改导致应用连接失败」对应「登录数据库改回原口令并刷新连接池」。回滚决策表不需要写多深但必须写明责任人和操作入口避免现场几个人围着一台机器争论半天。实际项目里这张表比任何加固说明都常被翻看。3. 把加固条目落到主机和中间件可抄作业的配置与命令3.1 账号口令与权限收敛从空口令到 sudo 白名单账号口令是每次加固实施最先开刀的地方也是最容易误伤的地方。先处理空口令和弱口令再做权限收敛。检查空口令和可登录账号的状态# 检测空口令账号RHEL/CentOS 系 awk -F: ($2 || $2 !!) {print $1} /etc/shadow逻辑说明/etc/shadow第二字段是加密口令空字符串表示未设置密码!!表示该账号从未设置过口令或已被锁定。输出了用户名后逐个处置确认不再使用的账号直接passwd -l还在用的账号立刻设置强口令。这里有个细节某些系统对锁定账号显示的是!而不是!!所以判断时最好把$2 !、$2 !!都算进去。密码复杂度策略放在/etc/login.defs和/etc/pam.d/system-auth两个地方。前者控制全局密码长度和时效# /etc/login.defs 关键参数 PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 9 PASS_WARN_AGE 14参数说明PASS_MAX_DAYS 90是 90 天强制改密PASS_MIN_DAYS 7防止改完马上又改回去配合历史记录才能拦住重复使用旧密码PASS_MIN_LEN 9设最小长度PASS_WARN_AGE 14提前两周提醒。注意PASS_MIN_LEN只对passwd命令的交互式修改生效不约束 root也不约束通过 SSH 密钥登录的账号所以它只是第一道门槛。真正限制弱口令要靠 PAM 的pam_pwquality模块里面可以设minlen、dcredit、ucredit这些复杂度参数。权限收敛的重点是 sudo 白名单和 UID 0 账号。先查 UID 0 的账号正常情况下应该只有 root# 列出 UID 0 账号和 sudo 组成员 awk -F: $3 0 {print} /etc/passwd getent group wheel如果发现第二个 UID 0 账号基本可以判定是后门要跟客户确认后立即删除。sudo 权限则按最小化原则收敛把客户现场管理员账号加入 wheel 组普通运维账号从 sudoers 里删掉。常见翻车点是某个应用账号在 sudoers 里配了ALL(ALL) ALL这类条目要收紧到「只允许执行指定命令」比如只允许systemctl restart nginx、tail -f /var/log/nginx/access.log。还有一个很多人忽略的点历史遗留的.rhosts、/etc/hosts.equiv这类 r 系列协议残留一旦开着等于给本机开了个后门。加固时直接确认这些文件不存在并把rexec、rlogin、rsh对应的服务端口检查一遍。3.2 SSH 加固改端口、禁 root 登录与密钥登录的先后顺序SSH 加固是翻车重灾区但不是因为配置复杂而是操作顺序不对。常见做法是先备份、再改配置、最后 reload 验证顺序不能反。# 备份并查看 sshd_config 当前关键项 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) grep -E ^(#)?(Port|PermitRootLogin|PasswordAuthentication|MaxAuthTries|AllowUsers) \ /etc/ssh/sshd_config先用 grep 把当前值拉出来看一眼再动手修改。改法推荐直接编辑文件而不是 sed 一把梭因为不同发行版默认配置差异很大sed 处理注释行容易出现重复项。以 RHEL/CentOS 为例一组常用的加固值Port 2222 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes MaxAuthTries 3 LoginGraceTime 30 AllowUsers ops monitor参数说明Port 2222避开默认端口但要注意和防火墙同步改PermitRootLogin no禁止 root 直连运维人员用普通账号登录后再su -PasswordAuthentication no关闭密码登录前提是已经把运维公钥写进~/.ssh/authorized_keys否则改完你就是被自己关在门外的人MaxAuthTries 3限制登录尝试次数配合LoginGraceTime 30缩短单次登录的窗口能挡掉一部分暴力破解。AllowUsers是最后一道闸把 SSH 可登录账号收敛到极少几个。这里有个特别重要的顺序先把公钥部署好、用新端口测试能登录再关闭密码认证最后再禁 root。公钥部署可以用ssh-copy-id完成部署后用第二个会话验证「密钥登录 新端口」链路是通的再动配置。否则一旦公钥权限不对或者端口被防火墙挡了你只能去机房。还有一个容易忽略的参数是ClientAliveInterval和ClientAliveCountMax。默认配置下空闲 SSH 连接可能挂一整天既占会话资源又扩大了被利用面。一般设ClientAliveInterval 300和ClientAliveCountMax 2表示 5 分钟没动静就发心跳探测连续两次无响应就断开。这个值对长任务有影响跑着后台任务的会话最好配合 tmux 或 nohup别让连接被服务端踢掉导致任务中断。验证 SSH 加固是否生效不要只看配置文件要看实际监听结果ss -tlnp | grep sshdss输出里如果监听端口已经是 2222且旧端口没有进程在监听才算配置真正生效。改完别忘执行systemctl reload sshd注意是 reload 不是 restartrestart 会短暂断开现有连接reload 则平滑生效。3.3 中间件与数据库加固Tomcat、Nginx、MySQL 的常见动作中间件加固和系统加固的差别在于中间件出了问题直接影响业务请求所以每改一个参数都要想清楚「这个参数背后是哪个业务路径」。以最常见的 Nginx、Tomcat、MySQL 为例。Nginx 的第一件事是隐藏版本号并清理不用的入口# nginx.conf 关键配置 server_tokens off;server_tokens off让响应头不再带nginx/1.20.1这类版本信息攻击者少了精确版本号找对应 CVE 的成本就高了。配套动作是检查默认 server 块把不用的location和alias路径清理掉特别是那些指向/etc/、/var/log/的别名路径曾经出过不少文件读取漏洞。Tomcat 的重点是管理端和自动部署。Tomcat 自带的manager、host-manager是渗透测试最喜欢的入口业务用不到就直接在tomcat-users.xml里注释掉对应角色并删除webapps/下的相关目录。server.xml里的autoDeploy也要关# 关闭 Tomcat 自动部署避免上传 JSP 后即时生效 sed -i s/autoDeploytrue/autoDeployfalse/ server.xml参数说明autoDeploy是热部署开关等于 true 时攻击者只要上传一个 JSP webshell 到webapps目录就会被自动加载执行这是 Tomcat 被拿下的常见路径。关掉之后部署新应用需要手工 reload运维会多一些操作但安全性提升明显。还要顺手确认disableUploadTimeout和请求体大小限制防止通过大请求体绕过 WAF 的检测。MySQL 加固的项目不多但每一条都可能踩雷。先跑官方自带的mysql_secure_installation处理匿名账号和测试库。需要额外注意的是MySQL 8 默认认证插件是caching_sha2_password如果应用连接串用的是老驱动改完认证方式可能导致连不上。另一个常见动作是关闭LOCAL INFILE和限制日志-- MySQL 安全相关参数 SET GLOBAL local_infile OFF; SET GLOBAL general_log OFF;参数说明local_infile控制是否允许通过LOAD DATA LOCAL INFILE读取客户端本地文件曾是被利用来读服务器敏感文件的入口之一关闭后对绝大多数业务无感知但如果有应用确实依赖本地文件导入必须在方案例外清单里写明并加白名单控制。general_log打开时会记录所有 SQL日志量极大且含敏感数据正常业务下保持关闭需要排查问题时再短时打开。数据库口令这一项要特别谨慎改口令前先查应用配置里用的是哪个账号连接串是明文还是加密改完口令后连接池是否会自动感知。稳妥做法是在低峰期改口令改完立刻触发一次应用重连测试不要等到第二天业务高峰再验证。很多项目就是改密码这一步没做全链路测试第二天早上应用全部报Access denied才回头来找我们。3.4 日志和审计加固完能回溯攻击路径才算闭环加固的最后一环是日志没有日志的加固等于白做出事之后你根本说不清楚攻击者是从哪条链路进来的。系统层面我一般开两样auditd的审计规则和远程日志转发。auditd的规则可以精确到文件级别# 审计 passwd、shadow、sudoers 等关键文件的写操作 auditctl -w /etc/passwd -p wa -k identity auditctl -w /etc/shadow -p wa -k identity auditctl -w /etc/sudoers -p wa -k privilege参数说明-w指定监控文件-p wa表示记录写和属性变更-k是打标签后续用ausearch -k identity可以快速过滤出这一类事件。规则要写成/etc/audit/rules.d/下的文件并执行augenrules --load否则重启后规则丢失只对当前内核生效。远程日志转发是配套动作把/var/log/secure、/var/log/messages、审计日志统一送到日志服务器# /etc/rsyslog.d/security.conf authpriv.* 192.0.2.10:5514 *.info;authpriv.none 192.0.2.10:5514参数说明authpriv.*是认证类事件远程收日志后本机即使被清理了痕迹日志服务器上还有一份。表示 UDP表示 TCP日志量大且要求可靠传输时用 TCP。日志服务器要单独划一个网段别让生产网段的任意主机都能访问 5514 端口否则日志服务器本身就是个巨大攻击面。日志这块要留意的是格式和时区。多台服务器如果 NTP 没对齐日志时间差出去几十秒事后溯源就对不上攻击时间线。加固方案里要把 NTP 对齐列为一个独立检查项实施完日志集中采集后挑三条测试日志确认时间戳一致。日志留存周期也要在方案里写清楚至少覆盖等保要求的期限超出磁盘容量就旋转归档别把日志目录撑爆导致应用写不了日志。4. 加固排障避坑业务没崩不算完隔天失效更要命4.1 重启后配置被覆盖初始化脚本、配置管理平台在打架现象加固完成后第三天客户反映服务器重启了一次再登进去发现/etc/ssh/sshd_config和密码策略全部回到加固前的样子等于白干。原因云主机上有初始化脚本每次启动会把一套默认配置写回去或者客户的配置管理平台定时从配置库拉取并下发配置把人工改动覆盖掉了。这两种情况在政企环境里非常常见。解决先确认这台机器是否被配置管理平台纳管如果有应先调整配置库里的基线而不是只改单机。有些客户会坚持先只改单机这时对配置文件加锁可以挡一阵# 对关键配置文件加不可变属性 chattr i /etc/ssh/sshd_config chattr i /etc/login.defs参数说明chattr i让文件变成不可修改连 root 也不能改所有程序写入都会报错覆盖动作自然失败。但它也是双刃剑以后任何合法修改都要先chattr -i解除忘了解锁就直接改会失败而且配置管理平台在同步时遇到只读文件会直接报错反而暴露配置漂移。所以我一般只建议对短期内无法改配置库的客户用锁同时把解锁命令写进交付文档。等客户把配置库基线更新后再统一解锁。4.2 端口关了又开防火墙规则和端口映射叠加现象实施人员用firewall-cmd封了 3306 端口外部扫描还是能扫到业务方质疑加固无效。原因要么是防火墙规则顺序不对先放行再拒绝要么目标是容器化部署容器的端口映射自带一套独立规则发布端口直接绕过宿主机防火墙还有可能是云平台安全组层面放行服务器本地防火墙根本管不着。这三种情况表现一样处置路径完全不同。解决先在目标机上确认端口到底谁在监听# 查看端口监听进程区分宿主机还是容器 ss -tlnp | grep 3306如果看到进程是docker-proxy就可以确定是端口映射放行。处置思路是优先改编排文件不让容器对外发布 3306 端口只保留容器网络内部访问如果短期内不能改编排至少要在云平台安全组层面把 3306 的入方向源地址收敛。注意不要只加本地防火墙规则就收工因为重启容器或 Docker 服务后发布规则会重新生成本地防火墙规则不一定拦得住。规则序的问题则用iptables -L -n --line-numbers检查把拒绝规则放到放行规则前面。4.3 业务登录态失效被顺手收紧的 TLS 版本和 session 存储现象加固完成后老用户登录系统频繁掉线部分老旧浏览器直接登录不上登录页报协议错误。原因排查后常见两类。一类是加固时把 TLS 1.0/1.1 协议关掉了客户内部老终端上的浏览器还停留在旧版本协议协商失败另一类是 session 存在 Redis加固时顺手改了 Redis 的监听地址或密码应用连不上 Redis 后 session 校验全部失败。解决TLS 的问题要先做兼容性评估再动。Nginx 和 Tomcat 的 TLS 版本配置改动前先统计客户端证书和终端浏览器占比必要时用中间版本过渡。Redis 这类通用存储组件在加固清单里要单独标注「影响 session/缓存的服务」变更后第一时间验证应用登录链路# 验证 Redis 连通性 redis-cli -h 127.0.0.1 -p 6379 -a $REDIS_PASSWORD ping返回PONG只代表组件层连接通还要再用应用的实际登录接口做一次全链路测试不能只看 Redis 本身。凡是动了 Redis 密码或监听地址的必须推动应用侧同步修改配置否则就是埋雷。session 失效这类问题有一个共性特征页面能打开但一登录就跳回登录页排查时先看 redis 连接日志再看应用日志里的 session 读取报错顺序不要反。4.4 生产环境翻车看着一样的环境回滚手段全不能用现象加固脚本在测试环境完整跑通拿到生产环境执行后数据库起不来回滚时发现备份文件是空的。原因测试环境和生产环境看起来版本一样细节却不同。比如数据库的数据目录权限生产环境可能被 DBA 手工改过加固脚本把数据目录权限从755收成750后MySQL 进程以mysql用户启动时读不到文件。回滚失败通常是因为备份只做了配置文件没做目录权限快照而且脚本执行时没做前置检查。解决加固脚本里每一步都要先做前置检查再执行至少包括三件事备份当前配置、记录当前目录权限、确认服务当前状态。可以写成统一的防护框架#!/bin/bash # 通用前置检查备份、记录权限、标记变更点 TS$(date %Y%m%d%H%M%S) for f in $; do cp -a $f $f.bak.$TS stat -c %n %a %U %G $f /var/log/reinforce_perms.$TS.log done echo backup completed at $TS参数说明cp -a保留属主、属组和权限备份的不是普通副本stat输出权限和属主写入日志回滚时可以直接按日志恢复$接收传入的文件路径脚本可以复用。还应该在脚本开头检测服务状态如果服务本来就处于异常状态立刻中止别把异常环境当成健康环境加固。生产环境执行的纪律也要在方案里写明每个批次的加固范围不超过 10 台跑完一批验证一批窗口期内不做跟加固无关的变更任何一步报错立即暂停不允许跳过报错继续执行。这些纪律看着繁琐却是翻车时唯一能保障后悔药有效的机制。我的习惯是每次生产加固都安排一个人专门盯着回滚不动手操作只在报错时大喊停这个人往往是项目里资历最浅的实习生但恰恰是这双眼睛救了多数场子。5. 验收交付把加固结果做成对方能复核的证据链5.1 交付物清单逐台可复核不是一张 Excel加固做完到验收之间最忌讳只交一份「已完成 xx 项整改」的表格。客户验收需要能复核的证据链我的交付物通常分成四类逐台主机的加固实施记录、配置变更前后的 diff 文件、回滚操作手册、加固后基线快照。其中配置 diff 是核心diff -u 备份 当前配置的结果直接证明你改了什么比任何描述都有说服力。5.2 一键复核脚本与长期巡检复核基线我会做成一个脚本验收时客户按同一份脚本重新跑一遍结果一致才算闭环#!/bin/bash # 加固复核脚本输出账号、SSH、端口、关键文件状态 echo 空口令账号 awk -F: ($2 || $2 !!) {print $1} /etc/shadow echo SSH 关键参数 sshd -T | grep -E permitrootlogin|passwordauthentication echo 防火墙规则条数 iptables -L -n | wc -l脚本输出要跟交付文档里的预期值一一对应比如PermitRootLogin no、PasswordAuthentication no、防火墙规则条数不少于某个值。只输出现状、不定预期验收时还是扯皮。长期巡检方面我会把同样的复核逻辑做成每周一次的 cron 或者接入客户的巡检平台一旦发现配置漂移第一时间告警。加固从来不是一次性的动作而是一个持续对抗配置漂移的过程。做安全服务这些年我养成了习惯每次交付前把自己当成客户重新走一遍复核流程能挑出三五个问题再回去改比到验收现场被业务方指着鼻子问强得多。希望这篇拆解对你接手下一个加固项目有帮得上忙的地方。本文还有配套的精品资源点击获取