企业官网建设流程全解析

简介：网络安全加固服务方案是一份面向网络安全工程师、解决方案架构师及等保合规人员的原创服务方案模板，可直接用于编写项目实施方案、投标技术文件或等保整改报告。压缩包内为单个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 sshd

ss输出里如果监听端口已经是 2222，且旧端口没有进程在监听，才算配置真正生效。改完别忘执行systemctl reload sshd，注意是 reload 不是 restart，restart 会短暂断开现有连接，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/autoDeploy="true"/autoDeploy="false"/' 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 或者接入客户的巡检平台，一旦发现配置漂移，第一时间告警。加固从来不是一次性的动作，而是一个持续对抗配置漂移的过程。做安全服务这些年，我养成了习惯：每次交付前把自己当成客户，重新走一遍复核流程，能挑出三五个问题再回去改，比到验收现场被业务方指着鼻子问强得多。希望这篇拆解对你接手下一个加固项目有帮得上忙的地方。

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