简介这份H3C网络安全系统规划方案投标建议书以doc文档形式呈现面向网络安全工程师、售前方案人员及参与政企安全项目投标的技术人员用于解决安全体系规划与整体方案设计缺乏参考模板的问题。文档围绕安全系统整体规划、网络及安全现状分析、网络安全整体解决方案三大板块展开涵盖方案设计原则、安全体系模型、网络结构与安全层次分析并从网络层、系统层、管理层、用户层逐层梳理安全需求进而给出基础设施安全部署、防火墙系统防护、内部入侵防御机制、端点准入控制、网络流量分析及病毒防范等具体设计内容目录结构完整、层次清晰。资源包共1个doc文件约1.21MB便于直接查阅与二次编辑。目前已有89人学习下载适合需要撰写安全规划方案、搭建安全体系框架或进行投标文档参考的读者借鉴使用。1. 一份投标建议书为什么值得当成技术方案来读很多人拿到「H3C网络安全系统规划方案投标建议书.doc」这个标题第一反应是把它归到售前文档里觉得跟一线技术关系不大。但真正做过政企、教育、医疗这类项目交付的人都清楚投标建议书里的技术部分往往就是后面实施阶段要照着落地的架构蓝图。它决定了设备选什么型号、安全域怎么划、策略怎么下、日志往哪送甚至决定了你后期排障时有没有后悔药可吃。这份文档的核心是把 H3C 的网络与安全产品线按客户业务需求组织成一套可交付、可验收、可运维的体系。它面向的是需要独立完成方案编写、设备选型、拓扑设计和报价支撑的工程师而不是只做单一设备调试的人。下面我按自己写这类方案的顺序把从需求拆解到设备清单、从安全域划分到策略落地的完整路径讲清楚中间会带上 H3C 设备上真实要敲的命令和参数。2. 从需求到拓扑H3C网络安全系统规划方案怎么搭骨架2.1 先分清客户要的是合规驱动还是攻防驱动写方案第一步不是翻产品手册而是判断项目性质。合规驱动的项目比如等保测评整改重点在边界隔离、日志留存、访问控制设备清单里防火墙、入侵防御、日志审计、堡垒机基本是标配。攻防驱动的项目比如参加网络安全赛事保障或红蓝对抗重点在流量可视化、威胁狩猎、快速封禁这时候 H3C 的态势感知平台和流量探针权重会明显上升。判断方法很直接看招标文件里的评分表。如果技术分里「符合等保三级要求」占大头就按合规路线写如果出现「实战化攻防」「威胁情报联动」这类词就往攻防路线靠。两条路线的设备选型差异很大混着写容易在评标时被挑出逻辑矛盾。2.2 安全域划分别把 VLAN 当安全域用很多新手写方案时直接把现有 VLAN 划成安全域这是典型的翻车点。VLAN 是二层隔离安全域是策略边界两者维度不同。正确的做法是先按业务重要性分三级核心业务区、普通办公区、外联接入区再在每个区内部按需细分。以典型的三层架构为例出口部署 H3C SecPath 防火墙做边界隔离核心区旁挂入侵防御系统办公区通过核心交换机划分 VLAN 后接入防火墙子接口。这里有个关键参数防火墙子接口的 MTU 建议设成 1500 以下比如 1400给 GRE 或 IPsec 隧道留出封装空间否则大包分片会拖慢跨域访问。# H3C 防火墙子接口配置示例 interface GigabitEthernet1/0/1.100 vlan-type dot1q 100 ip address 10.10.100.1 255.255.255.0 mtu 1400 quit这段配置的逻辑是在物理接口上创建子接口用vlan-type dot1q绑定 VLAN 100再配 IP 作为该安全域的网关。mtu 1400是给后续可能建立的隧道预留空间。参数说明子接口编号建议和 VLAN ID 保持一致方便后期排查IP 地址段要提前规划好避免和客户现有网段冲突。2.3 设备选型用吞吐和并发反推型号H3C 安全设备型号多选型时最容易犯的错是只看端口数量。正确做法是先算两个数峰值吞吐和最大并发连接数。峰值吞吐按核心业务带宽的 1.5 倍估算并发连接数按人均 200 到 500 条估算。比如一个 500 人的单位核心带宽 200M峰值吞吐需求约 300M并发连接数约 10 万到 25 万。对应到 H3C 产品线SecPath F1000 系列中端型号基本能覆盖。如果客户要求冗余就上双机热备这时候要注意心跳线必须直连不要经过交换机否则主备切换时延会明显增大。选型维度估算方法常见取值峰值吞吐核心带宽 × 1.5300M并发连接人数 × 200~50010万~25万新建连接并发数 × 10%1万~2.5万接口需求业务口 管理口 心跳口不少于 6 个千兆口表格里的新建连接参数容易被忽略但它直接决定设备在突发流量下会不会丢包。如果客户有大量短连接业务比如 Web 查询类系统新建连接指标要比并发数更重视。3. 安全策略与日志体系让方案能落地而不是只过评审3.1 策略编写从默认拒绝开始做减法安全策略的黄金法则是默认拒绝按需放行。但实际写方案时很多人为了省事写成默认允许再逐条拒绝这在等保测评里直接不合格。正确顺序是先配一条 any 到 any 的拒绝策略放在最底部然后按业务需求逐条插入允许策略。H3C 防火墙的策略匹配是从上到下所以允许策略要放在拒绝策略之前。每条策略要写清楚源域、目的域、源地址、目的地址、服务、时间范围。时间范围这个参数很多人不写结果策略 7×24 小时生效后期审计时说不清楚。# H3C 防火墙安全策略配置示例 security-policy ip rule 10 name Allow_Web_Access source-zone Trust destination-zone Untrust source-address 10.10.100.0 255.255.255.0 destination-address 172.16.1.10 255.255.255.255 service http https time-range WorkTime action pass rule 100 name Default_Deny action drop这段配置里rule 10的编号留出间隔方便后期插入新策略。time-range WorkTime引用预先定义的时间段只在工作时间放行 Web 访问。rule 100是兜底拒绝。参数说明策略编号建议按 10 的倍数递增源地址尽量精确到网段不要用 any否则策略审计时会被扣分。3.2 日志留存别等出了事才发现没记录网络安全基线检查里日志留存是硬指标。等保要求日志保存不少于 6 个月但很多方案只写「部署日志审计系统」没写清楚哪些日志要采、采多大、存哪里。H3C 设备支持把日志送到 Syslog 服务器也可以送态势感知平台。建议至少采三类日志会话日志、攻击日志、配置变更日志。会话日志用于溯源攻击日志用于告警配置变更日志用于追责。日志服务器容量按每天每设备 500MB 到 1GB 估算500 人规模的项目6 个月大约需要 1TB 到 2TB 存储。# H3C 设备日志外送配置示例 info-center enable info-center loghost 10.10.200.50 info-center source default channel loghost log level informational info-center timestamp loghost date这段配置开启信息中心把日志送到 10.10.200.50 这台日志服务器日志级别设为 informational时间戳用日期格式。参数说明日志级别不要设成 debugging否则日志量会暴涨时间戳必须带日期否则跨天排查时无法定位。3.3 高可用双机热备的心跳和切换参数方案里写双机热备不能只写「部署两台防火墙做 HA」要写清楚心跳接口、切换条件、切换时间。H3C 防火墙支持主备和负载分担两种模式主备模式配置简单负载分担模式利用率高但排障复杂。心跳接口建议用独立物理口直连不要走业务口。切换条件一般设成接口故障或链路故障切换时间控制在 1 到 3 秒。如果客户对中断敏感可以开启抢占模式但抢占延时建议设成 30 秒以上避免主备频繁切换。# H3C 防火墙双机热备配置示例 interface GigabitEthernet1/0/6 ip address 192.168.254.1 255.255.255.252 quit hotbackup enable hotbackup interface GigabitEthernet1/0/6 hotbackup track interface GigabitEthernet1/0/1 hotbackup preempt delay 30这段配置指定 GE1/0/6 为心跳口跟踪 GE1/0/1 的业务状态抢占延时 30 秒。参数说明心跳口 IP 用 30 位掩码只留两个可用地址track 接口要根据实际业务口调整preempt delay 太短会导致震荡太长会影响回切速度。4. 投标建议书里的技术参数怎么写才不被挑刺4.1 参数响应表用「满足」和「优于」区分评标时技术参数响应表是重点审查对象。常见错误是全部写「满足」结果被评委追问具体指标时答不上来。正确做法是核心指标写「优于」并附具体数值普通指标写「满足」不相关指标写「无偏离」。比如防火墙吞吐要求 200M你选型设备标称 4G就写「优于实测吞吐 4Gbps」。如果只写「满足」评委可能认为你刚好卡线印象分就低了。但也不能全写「优于」否则显得不真实一般「优于」占比控制在 30% 以内。4.2 拓扑图别只画设备不画流量拓扑图是方案的门面但很多人只画设备图标和连线不标流量方向和安全域边界。正确的拓扑图要包含安全域边界用虚线框标出流量方向用箭头标注关键设备旁写型号和接口。如果客户有多个出口比如同时接互联网和专线拓扑图上要明确标出哪条走防火墙、哪条走路由器。H3C 设备堆叠的场景要在图上标出堆叠线缆和主备关系否则后期实施时容易接错。4.3 报价支撑设备清单和维保要分开列报价部分最容易出问题的是维保。很多方案把设备和维保打包成一项结果客户砍价时连维保一起砍。正确做法是设备清单和维保服务分开列设备按台报价维保按年报价。H3C 设备的维保一般分基础服务和原厂服务基础服务响应时间 4 小时原厂服务可以做到 2 小时。如果客户是核心业务系统建议推原厂服务虽然贵但故障时能直接拉原厂工程师。普通办公区用基础服务就够了。5. 避坑与排查投标方案里没写但实施时一定会遇到的事5.1 现象防火墙策略放行了但业务不通原因策略匹配顺序问题或者 NAT 没配。H3C 防火墙如果做了源 NAT策略里的源地址要写 NAT 前的地址不是 NAT 后的地址。很多人在这里搞反导致策略看似放行实际被丢弃。解决先用display security-policy ip查看策略命中计数如果计数为 0说明流量没匹配到这条策略。再检查 NAT 配置确认策略里的地址是 NAT 前还是 NAT 后。实在不确定就临时加一条 any 到 any 的允许策略测试通了再逐条收紧。5.2 现象双机热备切换后业务中断超过 10 秒原因心跳口和业务口混用或者切换条件设得太敏感。心跳口如果走业务口业务口流量大时心跳报文会丢导致误切换。解决心跳口必须独立物理口直连不要经过交换机。切换条件只跟踪关键业务口不要跟踪所有接口。如果客户对切换时间要求高可以考虑负载分担模式但排障复杂度会上升。5.3 现象日志服务器收不到 H3C 设备日志原因日志级别设错或者路由不通。H3C 设备默认日志级别是 informational如果改成 debugging日志量太大会被服务器丢弃。另外设备到日志服务器的路由必须可达很多人只配了 IP 没配路由。解决先用ping测试设备到日志服务器的连通性再检查info-center source的日志级别。如果日志量确实大可以在日志服务器上按设备 IP 分目录存储避免单文件过大。5.4 现象堆叠口满了导致新设备加不进去原因堆叠口带宽不足或者堆叠线缆质量差。H3C 交换机堆叠时堆叠口建议用万兆口千兆口在流量大时容易成为瓶颈。解决先查display stack看堆叠状态如果显示异常检查线缆和光模块。堆叠口满了就加堆叠线缆做聚合或者换更高带宽的接口。堆叠成员数不要超过 4 台太多会影响收敛速度。5.5 现象设备启动失败Console 无输出原因电源故障、BootRom 损坏、或者配置丢失。H3C 设备启动失败时Console 口通常会有提示信息如果完全无输出先查电源和线缆。解决换电源线和 Console 线测试如果还是无输出可能是 BootRom 问题需要返厂。如果 Console 有输出但卡在某一步按提示进入 BootRom 菜单检查启动文件是否存在。配置丢失的话提前备份的配置文件就能派上用场。6. 把方案变成可复用的模板我的三个习惯写这类方案写了几年我最大的教训是不要每次从零开始。第一个习惯是建一个参数库把 H3C 常用型号的吞吐、并发、接口数、维保价格整理成表格下次选型时直接查表不用翻手册。第二个习惯是拓扑图分层画物理拓扑、逻辑拓扑、安全域拓扑分开存投标时按需组合。第三个习惯是策略模板化把等保三级、等保二级、攻防保障三类场景的策略框架提前写好实施时只改 IP 和端口。验证方案是否靠谱有个简单方法拿给没参与编写的同事看如果他能顺着拓扑图和设备清单把数据流向讲清楚说明方案逻辑是通的。如果他自己都绕晕了评委大概率也会晕。最后一个技巧是关于时间管理的。投标截止前三天不要再改技术方案只检查格式和错别字。技术方案改多了容易前后矛盾反而扣分。把时间花在报价核对和资质文件上性价比更高。希望帮到你。本文还有配套的精品资源点击获取