企业官网建设流程全解析

简介：一份面向网络管理员、信息安全工程师及企业IT负责人的网络安全加固方案PDF文档，围绕对外网信息系统在升级改造与安全防护中的整体需求展开。方案开篇梳理了项目背景、建设目标及参考标准，明确需求、风险、代价平衡分析，综合性、整体性、动态保护、一致性、强制性、易操作与多重保护等设计原则，并给出网络系统现状拓扑分析。核心部分重点阐述网络系统升级改造方案与安全加固技术方案，涵盖二层交换机替换、集中控管无线AP部署、POE供电、核心交换与安全设备UPS保障、安全设备部署及用途等落地细节，同时提供产品清单，便于实际采购与实施参考。资源包为1个pdf文件，大小约840KB，目录结构完整，内容覆盖从现状诊断到方案落地的全过程。目前已有353人学习下载，适合需要快速建立安全加固方案框架并对照项目实践的中高级技术人员使用。

1. 网络安全加固解决方案不是报告，而是要执行的“基线清单”

收到一份名为“网络安全加固解决方案.pdf”的文档，很多团队的惯性动作是存档、传阅、归档，然后等下次等保检查时再翻出来。这正好是本末倒置。真正有价值的网络安全加固解决方案，不是给审计看的合规材料，而是一份能照着实操的基线清单：它明确告诉你先加固什么、怎么做、参数改到什么程度、改完怎么验证。它的落地形态可以是PDF，但必须是“拿起来就能执行”的文档，而不是“看完觉得讲得很对”的文档。这篇笔记，我按自己做等保整改和应急加固的经验，把这个标题拆透：方案怎么设计、主机层和网络层怎么做、最容易踩哪些坑、以及怎么让这份方案不是一次性文件。

2. 设计加固方案的框架：先盘资产，再分三层，最后落到文档结构

2.1 加固的第一步不是“打补丁”，而是回答“资产在哪，谁在访问”

我见过太多团队拿到加固需求后，第一件事是登录服务器跑更新，结果三天后核心业务宕机，因为不知道那台服务器还承载着老旧的PHP接口。做网络安全加固解决方案，第一步永远是资产梳理。

资产梳理不是简单列IP，而是要建立一张“信息资产台账”，至少包含：主机名、IP、操作系统版本、中间件版本、开放端口、关联业务、负责人、数据等级。没有这张表，后面所有加固动作都是盲目的。我一般会用三个来源补齐台账：CMDB（如果有）、扫描器结果（Nmap或Masscan）、端口比较（用 ss -tlnp 和实际监听比对）。

端口梳理是特别容易漏的一环。很多主机自己以为只开了80和443，实际上一跑ss -tlnp发现还有22、3306、6379暴露在外网。排查时我会用下面的命令把监听端口和对应进程落盘：

ss -tlnp > /tmp/open_ports.txt # 同时把对外映射的IP也记下来 ip addr show | grep "inet " >> /tmp/open_ports.txt

逻辑说明：ss -tlnp列出所有TCP监听端口，-t是TCP，-l是监听，-n是不解析域名，-p是显示进程号。这些信息会告诉你端口被哪个进程占用，方便追溯到中间件或数据库。参数说明：如果你只想看对外暴露的地址，可以加上state listening过滤，或者用ss -tlnp | grep -v 127.0.0.1把本地回环过滤掉，剩下的一般就是需要重点关注的对外端口。完成这一步后，你才能在PDF里画出一张“网络拓扑+资产表”，这张表决定后续防火墙白名单怎么写、补丁优先级怎么排。

2.2 三层加固模型：主机层、网络层、应用层各自的武器

网络安全加固解决方案的框架，我习惯按“主机层、网络层、应用层”三层来拆。这不是什么新理论，但能保证不遗漏。主机层解决的是“这台机器本身脆不脆”，包括账号口令、补丁、SSH配置、文件权限、内核参数；网络层解决的是“谁能到这台机器”，包括防火墙策略、DNS过滤、入侵检测、恶意流量阻断；应用层解决的是“运行在这台机器上的业务有没有漏洞”，包括Web中间件配置、WAF规则、接口鉴权、日志审计。

工具选型上，不要盲目追求商业套件。开源的OpenSCAP、Lynis、ClamAV（查毒）、Fail2ban（防爆破）、Suricata（IDS）完全够用。商业产品如某企业版加固工具，重点在于策略集成的便利性，但如果你只是做内网合规和防御，开源基线工具加上自定义脚本，效果不会差太多，而且可控性更强。我一般会在方案里列出每个层面对应的工具名、适用版本、输出格式，让读者照着选即可。

三层模型的价值还在于“定优先级”：主机层最容易见效，网络层能挡住大半扫描和爆破，应用层最繁杂但直接影响业务安全。按照“先主机，再网络，后应用”的顺序推进，每完成一层就做一次回归验证。这样方案不会变成“一次全堆上去，出事了找不到根因”。

2.3 把方案落成PDF前的结构设计：每条加固项要有“目的、操作、验证、回滚”

一份能执行的网络安全加固解决方案，文档结构不能是纯散文。我写PDF时固定用四列式清单：加固项、目的、操作步骤、验证方法与回滚方案。每一行就是一个可以单独验收的最小工作单元。实际操作中，直接把这份清单打印出来，逐条打勾，比看一百页理论更高效。

章节设计按资产盘点、主机加固、网络加固、应用加固、监控与应急来组织。其中“验证方法”是绝大多数PDF里最容易被忽视的部分。比如“关闭SSH root远程登录”这一项，验证方法应该是“用root用户ssh远程连接，确认被拒绝；用普通用户登录后su，确认可切换”。没有验证，就没有闭环。回滚方案也很重要——至少写明“备份原配置文件，改动前执行 cp 备份，验证失败后恢复”。用这种结构写出的PDF，才能真正替代口头经验。

3. 主机层加固实操：账号口令、SSH配置、基线与补丁

3.1 账号与权限收敛：从 /etc/passwd 到 sudoers 的逐项检查

主机层加固先说账号，因为这是最容易出突破口的点。常见的错误是系统中存在很多长期不用的普通用户，甚至有人把默认用户口令设成了弱口令。我建议把它作为第一个清零项。

检查账号时需要列出所有用户以及UID、组、登录shell。高权限用户（UID 0）尤其要关注。另一个重点是sudoer列表，因为很多攻击者拿到普通用户后，会尝试利用sudo配置错误提权。下面这个脚本可以快速产出账号审计报告：

# 列出所有可登录用户（shell不是nologin/false） awk -F: '$7 != "/sbin/nologin" && $7 != "/usr/sbin/nologin" && $7 != "/bin/false" {print $1, $3, $6, $7}' /etc/passwd # 检查UID 0的特权账号 awk -F: '$3 == 0 {print $1}' /etc/passwd # 检查sudoers中有NOPASSWD的条目 grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/ 2>/dev/null

逻辑说明：第一条命令提取所有可以登录系统的普通用户，UID 0 的账号只有 root 和特意配置的管理账号才算正常。第二条命令就是为了找出可疑的“影子root”。第三条检查 sudo 时不需要密码的配置，这种配置虽然方便，但一旦被利用就相当于无口令提权。参数说明：-F:指定字段分隔符为冒号；$3 == 0表示第三个字段UID为0。如果你的环境是FreeBSD或Solaris，路径会不同，需要相应调整。

发现问题后，处置方式很直接：删除或禁用空密码用户、设置密码策略（天数、长度、复杂度）、把sudo权限收敛到最小集合。密码策略统一通过/etc/login.defs和/etc/pam.d/system-auth来管理。我一般会设置PASS_MAX_DAYS 90、PASS_MIN_LEN 12，并且启用pam_pwquality.so。注意，这个改动会影响所有存量用户，需要提前通知业务负责人。

3.2 SSH加固：五种必须改的配置与密钥认证

SSH是运维的生命线，也是被爆破的重灾区。默认的22端口加上root口令登录，基本等于把门打开。这里给出一个最小加固集，适用于Linux平台。先备份配置文件再改，这是铁律。

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) # 修改以下参数（推荐值已标注） sed -i 's/^#Port 22/Port 2232/' /etc/ssh/sshd_config # 换端口，减少扫描 sed -i 's/^#PermitRootLogin prohibit-password/PermitRootLogin no/' /etc/ssh/sshd_config sed -i 's/^#MaxAuthTries 6/MaxAuthTries 3/' /etc/ssh/sshd_config sed -i 's/^#PubkeyAuthentication yes/PubkeyAuthentication yes/' /etc/ssh/sshd_config sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config # 校验配置语法，然后重启 sshd -t && systemctl restart sshd

逻辑说明：这一组命令同时做了四件事——更换SSH监听端口、禁止root直接远程登录、限制每连接最大认证尝试次数、强制使用公钥认证并关闭口令认证。参数说明：端口建议取一个不冲突的高位端口，比如2232，但必须同步更新防火墙放行策略，否则改完会把自己锁在外面。PermitRootLogin no意味着root无法直接登录，但可以用普通用户su -切换。MaxAuthTries 3能大大降低暴力破解的成功率。PasswordAuthentication no是最关键的一项，关闭后即使口令被猜中也进不来，前提是密钥已经配置完成且可用。

改完后，必须用另一个终端验证登录。如果密钥没有配置好，你会在新会话里被拒绝。所以顺序应该是：先配置好公钥、打开密钥认证、测试登录成功后再关闭口令认证。我有一个习惯：在sshd_config里同时保留一条Match Address 10.0.0.0/8的例外允许root登录，用于堡垒机网络的紧急跳转。这个可以作为选项，但不要全公司都这么做。

3.3 补丁与基线检查：用OpenSCAP把安全基线“量化”

账号和SSH是手工项目，补丁和基线则适合用自动化工具来扫。OpenSCAP是社区使用最广的基线检查工具，它把CIS、STIG等基线转换成可执行的XML规则，扫描后输出报告。用它来生成PDF方案里的“整改前基线状态”，非常有说服力。

先安装并扫描：

yum install -y openscap-scanner scap-security-guide oscap xccdf eval \ --profile xccdf_org.ssgproject.content_profile_cis \ --results /tmp/scan-results.xml \ --report /tmp/scan-report.html \ /usr/share/xml/scap/ssg/content/ssg-centos-7-ds.xml

逻辑说明：这条命令使用SCAP安全指南中的CIS profile对系统做基线扫描，结果同时输出为XML和HTML报告。其中HTML报告可以直接作为PDF的附录，里面逐条写明“通过/失败”。参数说明：--profile指定基线标准，CIS是等保和日常运维都比较认的标准；--report生成网页版报告，方便浏览器查看。如果你的系统是RHEL8或9，对应的ds.xml路径会变成ssg-rhel8-ds.xml。扫描完成后需要重点看“失败”项，那些才是真正要修的。注意，OpenSCAP的基线规则可能和某些业务自定义配置冲突，比如/etc/issue的内容，需要评审后再自动化修复。

补丁管理这块，内网环境建议用自行搭建的镜像源或wsus，不能直接在生产环境执行yum update -y这种全量更新。我的做法是：先在测试环境跑一轮yum check-update生成更新列表，过滤掉涉及内核和驱动的大版本更新，然后把剩余更新应用到生产。内核更新需要重启，要有维护窗口。在PDF方案里，补丁章节必须写明“分批、可回滚、重启窗口”，而不是一句“定期更新”。

4. 网络层加固与恶意流量处置：防火墙、DNS过滤、检测规则

4.1 防火墙最小化策略：先默认拒绝，再按业务白名单放行

网络层加固的第一原则是“默认拒绝”。但很多生产防火墙在实施时，管理员会嫌麻烦，继续用“默认放行，只封几个端口”的做法。这不是加固，这是摆设。正确的做法是新建一套规则集：先清空，再逐条添加业务所需的端口，最后把默认策略改成drop。

以firewalld为例：

# 清空默认zone的规则，创建业务zone firewall-cmd --permanent --new-zone=production firewall-cmd --permanent --set-default-zone=drop # 只允许必要端口（根据资产盘点结果） firewall-cmd --permanent --zone=production --add-service=ssh firewall-cmd --permanent --zone=production --add-port=80/tcp firewall-cmd --permanent --zone=production --add-port=443/tcp firewall-cmd --permanent --zone=production --add-source=192.168.10.0/24 # 加载规则 firewall-cmd --reload

逻辑说明：先把默认zone设为drop，这样未明确放行的流量全部丢弃；然后新建production zone，把业务网段和端口绑定进去。这里的顺序有讲究：必须先添加source，再允许端口，否则放行会失效。参数说明：--add-source指定可信的源IP段，用于限制只有办公网或内网可以访问管理端口；--add-port的协议默认是tcp，需要udp时写成80/udp。如果你用的是iptables命令行的环境，可以用iptables-save导出规则备份，再逐条插入。注意，设置默认drop前务必确认你当前连接的IP在放行规则里，否则执行完--reload后自己会被断掉，这是翻车频率最高的操作。

4.2 恶意域名与黑产团伙的处置流程：阻断、DNS过滤、日志溯源

标题里提到的“恶意域名反复攻击”场景，其实是很多企业内网会遇到的真实问题。某个恶意域名不断尝试连接，可能来自失陷主机上的后门，也可能是黑产C2。处置不能只封IP，因为IP会变，域名才是稳定的控制通道。我的标准流程是五步：阻断、过滤、溯源、加固、监控。

第一步，在网络出口和主机本地同时做域名级阻断。Linux主机上可以用hosts文件强制解析到127.0.0.1，但更好的办法是使用dnsmasq或unbound做DNS过滤，在DNS层面直接返回黑名单。例如在dnsmasq配置中加入：

echo "address=/malicious-domain.example/0.0.0.0" >> /etc/dnsmasq.conf systemctl restart dnsmasq

逻辑说明：这条配置让dnsmasq对恶意域名的解析直接返回0.0.0.0，使依赖该域名的木马无法获得真实IP，从而断开C2连接。参数说明：格式是address=/域名/返回值。如果想阻断整个域名及子域，就写domain，但dnsmasq的泛域名支持有限，更完整的方案是配置server=/恶意域名/0.0.0.0或使用rpz规则。对于大规模内网，应当在核心DNS服务器上做响应策略（RPZ），而不是逐台改hosts。

第二步是溯源分析。我通常会把防火墙和dnsmasq的日志集中收集，然后查有哪些主机解析了恶意域名。命令如下：

# 模拟从日志中过滤恶意域名解析记录 grep "malicious-domain.example" /var/log/dnsmasq.log | awk '{print $6}' | sort | uniq -c # 找出对应的源IP和进程 ss -tnp | grep '<恶意IP>:'

逻辑说明：第一条命令统计解析恶意域名的客户端数量，第二条命令查看当前是否有主机正在与恶意IP建立连接。找到源IP后，再去那台主机上检查进程，配合ls -l /proc/<PID>/exe确认是否后门。参数说明：$6是dnsmasq日志中客户机IP所在字段，实际字段位置可能因版本不同有偏差，建议先tail -5确认格式。这一步的目的是定位失陷主机，而不是只把域名封掉了事。封域名只是止血，杀进程和清持久化才是治本。

4.3 用IDS规则与WAF配置把“未知流量”暴露出来

网络层的第二道防线是入侵检测。我常用Suricata，落地时把规则集分成基础规则、恶意域名规则、业务特定规则三层。对于恶意域名已经确定的情况，可以直接写一条自定义规则来告警：

alert dns any any -> any any (msg:"Known malicious domain detected"; dns.query; content:"malicious-domain.example"; nocase; sid:1000001; rev:1;)

逻辑说明：这条规则匹配DNS查询请求，只要query字段里出现恶意域名就产生告警。dns.query是Suricata针对DNS协议提取的字段，content后面是匹配内容，nocase表示忽略大小写。参数说明：sid是规则唯一编号，自定义规则建议从1000000以上分配，避免和默认规则冲突。rev是版本号。规则要放到/etc/suricata/rules/下的自定义文件里，然后在suricata.yaml中引用。

WAF方面，如果业务有Web入口，我会在Nginx层配置简单的拦截规则，或者用ModSecurity。比如阻止常见的SQL注入探测：

# nginx location中启用modsecurity并加载OWASP CRS规则 modsecurity on; modsecurity_rules_file /etc/nginx/modsec/crs/ruleset.conf;

逻辑说明：ModSecurity配合OWASP CRS规则集能拦截大量Web攻击。但要注意，启用默认规则后可能产生误杀，比如某些业务参数被当作XSS或SQL注入。参数说明：modsecurity_rules_file指向规则集主文件，实际使用时建议先开启“检测模式”只记录不拦截，跑一周看错误日志，再切换到拦截模式。这是应用层和网络层的结合部，也是踩坑最密集的地方。

5. 加固落地中的常见坑与排查：现象、原因、解决

5.1 加固后业务连接被拒：源头是默认策略改为drop后没放行回程流量

现象：网络层把默认策略改成drop后，应用访问时断时续甚至完全不通，但端口确实已经放行。

原因：很多firewalld/iptables的规则只写了入方向允许，没有考虑状态跟踪。如果防火墙没有开启conntrack，或者iptables规则里缺少ESTABLISHED,RELATED的放行，那么业务返回的数据包会被当成新连接丢掉。

解决：在入口规则最前面加状态放行。firewalld下，确保zone中的服务不要直接依赖“新建连接”规则，而是使用firewall-cmd --permanent --zone=production --add-masquerade会带来问题，更好的做法是使用iptables时这样处理：

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

测试顺序也应调整：先放行已建立连接，再放行业务端口，最后把默认策略设为drop。我用这条经验救回过不少线上故障，尤其是数据库回程连接被掐断的场景。

5.2 SSH改端口后连接被拒：防火墙和SELinux没有同步放行

现象：修改sshd端口并重启后，从远程无法连接，但服务器本机能够正常登录。

原因：首先想到防火墙，放行新端口后还是不行。其实还有一个隐藏点：SELinux。如果系统启用了SELinux，sshd_t 域默认只允许监听22端口，你通过semanage把新端口类型改成ssh_port_t。否则SELinux会拦截监听行为，sshd虽然进程活着，但端口根本没绑定。

解决：执行以下命令并确认结果：

# 查看SELinux是否开启 getenforce # 允许SSH监听新端口 semanage port -a -t ssh_port_t -p tcp 2232

逻辑说明：semanage port -a是添加端口映射，-t ssh_port_t指定安全上下文，-p tcp指定协议。注意，如果原来没有允许过，会出现“值无效”的报错，可以先semanage port -l | grep ssh看现有定义。参数说明：新端口必须和sshd_config中的Port值保持一致，而且要同时改firewalld和SELinux。很多加固手册只提防火墙，不提SELinux，这就是最大的坑。如果实在不熟悉SELinux，可以在遵循最小权限的前提下用setsebool -P ssh_sysadm_login on放宽某些限制，但不要彻底disable SELinux。

5.3 补丁工具自动修复后，业务进程起不来：基线规则的“一刀切”问题

现象：运行OpenSCAP自动修复后，某个Java应用无法启动，报错是权限拒绝。

原因：OpenSCAP的某些CIS规则会收紧文件权限和目录权限，比如因为合规要求，/etc/passwd必须为644，但业务应用写到/var/log的权限被变更，或者Java临时目录被设置了noexec。这种“规则正确，业务不允许”的冲突是常态。

解决：不要在默认修复模式下跑所有规则。我的做法是先出扫描报告，逐条review“fail”项，把业务运行必需且“不影响安全”的规则加上免责注释，例如--remediate参数只用于修复已知无冲突的项。具体操作是在扫描时用--tailoring-file自定义一个裁剪文件，或者直接手动修复一部分。另外，任何基线扫描工具的自动修复，在Windows和Linux上都必须启用“变更前备份”，这一点大多数文档不会强调。

5.4 恶意域名被封后仍然反复出现：没有清掉持久化宿主

现象：DNS过滤生效后，告警暂时消失，但几天后同一个恶意域名又出现在日志中。

原因：分析时只封了网络层，没有追到主机上的后门。黑产团伙往往会同时运行多个进程，甚至利用crontab、systemd timer定期重新下载新的木马样本。重启后木马又复活了。

解决：处置流程必须包含主机取证：使用chkrootkit或rkhunter扫描后门，重点检查计划任务、启动项和驱动模块。命令：

# 查看所有用户计划任务 for user in $(cut -f1 -d: /etc/passwd); do crontab -l -u $user; done # 检查systemd定时器 systemctl list-timers --all --no-pager

逻辑说明：第一条命令遍历所有用户查看crontab内容，第二条列出所有systemd timer。后门通常会注册一个保活定时任务。参数说明：如果发现异常任务，先通过ls -l /proc/<PID>/exe找到进程路径，然后确认该任务的脚本内容，最后删除任务文件并清除相关二进制文件。不要指望断网就能彻底解决，必须溯源到根因。这一步做完，才算“处置完毕”。

5.5 日志被清空导致溯源中断：集中收集与只读存储是标配

现象：攻击者拿到了主机权限，删除了/var/log/secure和/var/log/messages，导致无法回溯入侵路径。

原因：单机日志默认存本地，任何拿到root权限的攻击者都能清掉。这不是你加固失误，是架构上没有做日志防线。

解决：部署日志集中采集，最简单的方式是使用rsyslog将日志实时发送到远程日志服务器，同时在网络边界通过镜像端口留存全流量。

# rsyslog配置示例，将auth和内核日志转发到远程日志中心 echo '*.info @192.168.1.100:514' >> /etc/rsyslog.conf systemctl restart rsyslog

逻辑说明：这条配置让rsyslog把所有info以上级别的日志UDP发送到远程日志服务器192.168.1.100的514端口。参数说明：@表示UDP协议，@@表示TCP协议。内网建议用TCP保证不丢包。远程日志服务器需要配置磁盘空间告警，只读挂载更好。在加固方案PDF中，这一条必须放在监控与审计章节，并且明确要求实现“日志至少保留180天”。

6. 让加固方案持续有效：基线检查自动化与定期验证

加固不是一次性项目，而是持续性的运维动作。我会把前面写的OpenSCAP基线扫描命令放进cron，每周自动跑一次，并把HTML报告发送到指定的审计邮箱或者内部wiki。这里分享一个自己用了很久的组合：用oscap配合report参数生成报告，再用脚本根据报告标题里的“failed”数字判断是否触发告警。

#!/bin/bash # 每周日凌晨2点执行扫描并生成报告 0 2 * * 0 \ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \ --results /var/lib/oscap/results-weekly.xml \ --report /var/lib/oscap/report-weekly.html \ /usr/share/xml/scap/ssg/content/ssg-centos-7-ds.xml \ && curl -F "file=@/var/lib/oscap/report-weekly.html" http://wiki.internal/upload 2>/dev/null

逻辑说明：这行cron将每周日的扫描结果上传到内部wiki，方便安全团队和运维团队共同查看。参数说明：&&表示扫描成功后才上传，避免上传空的失败报告；curl -F是用表单方式上传文件，如果你的wiki不支持，可以用scp或者做成邮件附件。注意扫描会消耗CPU，建议放在业务低峰期。

除了自动化扫描，我每个月还会手动做一次“最小权限验证”：用普通用户尝试执行 sudo -l，确认没有新增的提权路径；用nmap从外部扫一遍核心端口，确认没有新增暴露；再随机挑一台机器检查/tmp下是否有可疑的可执行文件。这些动作虽然简单，但能防止加固措施随着时间的推移被业务人员悄悄改回去。

最后说一个个人教训：我最初设计加固方案时，总想把所有安全项都调到最强，结果业务不断来报障，最后被迫回滚了一半规则。后来我记住了“加固的底线是业务连续性”。每一步操作都要写回滚方案，每一个参数都要留余地，比如SSH的MaxAuthTries设为3而不是1，比如WAF先观察再拦截。安全方案不是越硬越好，而是在可控范围内尽可能封闭。这份淡化在PDF中的原则，才是方案能落地的关键。希望帮到你。

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