企业官网建设流程全解析

1. 安全基线是干什么的：先搞清楚你手上这台设备到底安不安全

我在企业里做网络和安全管理有些年头了，接手过不少华为的设备，从CE系列数据中心交换机、AR系列企业路由器，到USG系列防火墙都摸过一遍。每次新入场或者做安全自查，第一件事永远不是急着配策略，而是先做一遍安全基线检查。

很多刚入行的朋友容易把安全基线理解为“装个杀毒软件”“改个强密码”就完事了，其实差得很远。安全基线，本质上是给一台设备定义一个“最低安全配置线”——低于这条线，设备就不应该被允许上线运行。它是安全合规检查和等保测评的底层依据，也是日常运维里判断设备是否处于安全状态的一把标尺。

我举个例子你就明白了。你买了一台华为AR路由器，默认配置下它其实开着很多用不上的服务：HTTP管理、FTP传输、SNMP只读或读写团体字。这些服务在局域网的隔离环境里可能感觉不到威胁，但一旦设备被部署到办公网出口甚至生产网边界，每一个多余的服务都是攻击者踏进内网的一扇门。安全基线做的事情，就是把该开的服务白名单化，该关的服务一律关掉，账号策略、登录策略、日志策略逐项卡到位。

这篇文章我基于自己实际执行过的华为安全基线核查和加固过程，整理了从检查项拆解、命令配置到整改验证的完整路径。适合三类人看：一是刚接手华为设备但不知道从哪下手做安全自查的运维，二是正在准备等保测评、被测评机构追着要整改证据的安全工程师，三是想把自己管理的网络设备提升一个安全档次的网络管理员。内容全部基于最常见的华为VRP平台（V800系列版本适用），防火墙部分会单独说明。

先说一个核心结论：安全基线不是一份静态文档，而是由账号口令安全、服务管理安全、登录安全、日志审计安全、协议安全加固这几个维度共同构成的一整套检查动作。下面我一个一个拆开讲。

2. 账号口令和登录安全：安全基线的第一道闸门

2.1 本地用户与口令策略：别让弱口令成为突破口

华为设备默认的本地账号管理体系里，最容易被忽略的坑是这些：默认admin账号没停用、口令策略没开启、登录超时时间默认不限制、连续失败不锁定。我在实际检查中见过不少设备，console口和VTY口都放着同一个默认密码，改都没改过。

在华为VRP平台上，账号口令安全需要从这几项落实：

第一，开启全局口令复杂度策略。通过aaa视图下的password-policy命令启用，配置最小长度至少10位，必须包含大写、小写、数字、特殊字符中至少三类。VRP平台默认的口令策略并没有那么严格，需要人工介入。

[Device] aaa [Device-aaa] password-policy [Device-aaa-password-policy] password length 10 [Device-aaa-password-policy] password complexity at-least 3 [Device-aaa-password-policy] password expire 90 [Device-aaa-password-policy] password history 5

这里多说一句关键是password history 5。它的意思是新密码不能跟最近5次历史密码相同，这个参数能有效防止用户来回改两个密码糊弄检查。我见过只开了长度和复杂度、没开历史的设备，隔三个月再看，密码还是老样子。

第二，账号锁定策略必开。暴力破解是登录层面最直接的攻击方式，如果VRP没有锁定机制，扫密码的工具可以一直跑。配置位置同样在password-policy下面：

[Device-aaa-password-policy] password retry-time 5 [Device-aaa-password-policy] password lock-time 5

含义是连续输错5次，锁定5分钟。这个参数不是越长越好——我在生产环境踩过坑，把锁定时长设成30分钟，结果有同事在交换机上连续输错了几次，整台设备的登录直接被锁半小时，办事的人在外面干瞪眼。5到10分钟是比较务实的区间。还有一个细节：retry-time建议不要小于3，否则正常人类手误几次就把自己锁住了。

第三，删除或禁用默认账号。华为设备默认的管理员账号是admin，如果你还在用它，必须改掉。最稳妥的做法是新建一个私有管理账号，然后把默认admin账号删掉或者至少降低权限。操作方式：

[Device] undo local-user admin

当然，执行之前要百分之百确认新账号已经有了管理权限并且能正常登录，否则手一抖把自己锁在设备外面，那就得跑机房串口了，这种事情在运维圈里属于“有味道的事故”。

2.2 登录方式加固：SSH替代Telnet，ACL限制管理源

华为设备默认开启Telnet服务的情况太常见了。Telnet的流量是明文传输，用户名密码在网络里裸奔，抓包软件一抓一个准。安全基线的要求很简单——禁用Telnet，启用SSH，并且限制登录源地址。

启用SSH的配置路径：

[Device] rsa local-key-pair create [Device] user-interface vty 0 4 [Device-ui-vty0-4] authentication-mode aaa [Device-ui-vty0-4] protocol inbound ssh [Device-ui-vty0-4] acl 2001 inbound

关于ACL限制登录源这段，值得展开说说。ACL 2001里应该只放行运维跳板机的IP地址。配置方式是：

[Device] acl number 2001 [Device-acl-basic-2001] rule 5 permit source 192.168.10.10 0 [Device-acl-basic-2001] rule 10 deny

这个配置的效果：只有192.168.10.10这一台机器能SSH登进设备，其他任何地址全部拒绝。我在做安全基线加固时永远把这条放在前面做，因为如果先关了Telnet开了SSH但没限制源地址，等于把原来那扇没锁的门换成了一个半掩着的门——理论上好一点，实际上暴露面还在。

还有一点特别容易翻车的地方：VTY视图下如果执行protocol inbound all，那就等于同时允许Telnet和SSH，基线检查直接不通过。VTY的protocol inbound必须明确指定为ssh。

console口同样需要关注。如果物理安全不受控（比如设备放在公共服务区或开放机房），console口默认密码强度不足时，相当于给能物理接触设备的人留了一把钥匙。建议在console口也启用AAA认证并设置独立的强密码。

3. 服务与端口加固：关掉所有用不上的“门”

3.1 设备管理面服务最小化：HTTP、FTP、SNMP逐个过

华为设备默认开启的很多服务，在日常业务里根本用不上，但它们都是实打实的风险面。安全基线里“服务最小化”原则，说白了就是只保留业务需要的最小服务集合，其他一律关停。

先列一份我在基线检查时必查的服务清单和对应处理命令：

HTTP管理服务是重灾区。我见过不止一台交换机的Web管理界面开着，暴露在办公网里，管理员图方便用浏览器登录。且不说HTTP明文传输的问题，Web管理界面本身也是漏洞高发区。基线要求：能关就关，实在要开只开HTTPS，并且绑定ACL限制访问IP。

SNMP这块水很深。SNMPv2c的团体字是明文的，public、private这类默认团体字在网络里约等于把你的设备配置透传给任意一个能发包的人。基线的硬性要求是禁用SNMPv2c及以下版本，如果业务确实需要网管平台监控，迁移到SNMPv3，启用认证和加密：

[Device] snmp-agent [Device] snmp-agent sys-info version v3 [Device] snmp-agent group v3 group_priv privacy [Device] snmp-agent usm-user v3 monitor_user group_priv acl 2001

加在最后的acl 2001是限制网管服务器地址能访问SNMP服务。很多人在配置SNMPv3时漏掉这个限制，导致全网任意主机都能向设备发起SNMP请求。即使认证加密做得再好，暴露面小一点总归是好的。

3.2 协议层安全加固：STP、ARP、DHCP一个都不能漏

除了管理面服务，设备自身运行的二层协议和底层协议也需要纳入安全基线范围。这部分容易被忽略，但恰恰是局域网攻防里最常被利用的环节。

STP（生成树协议）的防护，核心是BPDU Guard和Root Guard。如果不做防护，攻击者往接口上插一台普通PC，用软件伪造BPDU报文，就能在几秒钟内成为根桥，篡改整个交换网络的数据流向，这种攻击做起来很容易，难的是事后排查。对应配置：

[Device-GigabitEthernet0/0/1] stp edged-port enable [Device-GigabitEthernet0/0/1] stp bpdu-filter enable [Device-GigabitEthernet0/0/1] stp bpdu-protection

edged-port是把接口配成边缘端口（接终端设备用的），bpdu-filter在边缘端口上过滤BPDU，bpdu-protection是当边缘端口收到非法BPDU时，直接把端口error-down。这套组合拳的效果是：新接入的设备想搞STP攻击，端口会立刻被隔离，运维日志里会留下记录。

ARP欺骗在办公网里更常见。攻击者在局域网里伪造网关的MAC地址，所有流量都会绕经攻击者的机器，账号密码、文件内容全部被旁路监听。华为设备上做ARP防欺骗主要依赖DHCP Snooping + DAI（Dynamic ARP Inspection）组合：

[Device] dhcp enable [Device] dhcp snooping enable [Device-GigabitEthernet0/0/1] dhcp snooping enable [Device] arp anti-attack check user-bind enable

dhcp snooping会建立一个合法的IP-MAC绑定表，arp anti-attack check user-bind则基于这张表校验ARP报文。不在白名单里的ARP请求直接被丢弃。这套方案依赖DHCP Snooping的绑定表，所以接入交换机必须开启DHCP Snooping，终端获取IP的报文才能被记录到表里。如果设备里存在静态IP地址的终端，需要在全局视图下手动添加绑定表项。

4. 日志与审计：出事之后你得知道发生过什么

4.1 开启日志同步，避免单机日志丢失

很多设备默认开着日志，但只是存在本地缓存里，设备一重启，日志全没了。安全基线对日志的要求很简单也很关键：必须同步到远程日志服务器，并且至少保存6个月以上。如果你不做，出了安全事故等需要回溯的时候才发现日志早就没了，那时一切都晚了。

华为设备同步日志到远程服务器的配置：

[Device] info-center enable [Device] info-center loghost 192.168.100.50 [Device] info-center source default channel loghost log level informational

这里有个关键细节很多人不知道——info-center source default channel loghost log level informational这条命令，定义了哪些模块的日志以什么级别发往日志服务器。只配置info-center loghost但没配source策略的情况下，部分模块的日志可能不会同步。我在检查中遇到过客户设备管理口配置了loghost，但折腾半天服务器上一条日志都收不到，最后排查下来就是source策略缺失。

配置完记得在设备上测试连通性，用ping 192.168.100.50确认管理口能通日志服务器。日志服务器端也要提前打开UDP 514端口。另外要注意的是，华为设备日志默认发送到loghost的端口是UDP 514，如果日志服务器监听的是其他端口（比如TCP 514或者UDP 1514），需要额外指定port参数。

日志这块另一个容易忽略的是时钟同步。设备本地时间不准的话，日志时间戳根本没法作为审计证据。NTP同步建议直接做成基线标配：

[Device] ntp-service unicast-server 192.168.100.1 [Device] ntp-service authentication enable [Device] ntp-service authentication-keyid 1 authentication-mode hmac-sha256 cipher 密码 [Device] ntp-service reliable authentication-servers 1

NTP认证这步很多老工程师都没做，理由是“内网没事”。但说实话，NTP欺骗并不是什么高深的攻击手法，伪造一个NTP响应让设备时间跳变，日志作废，认证票据失效……这些后果在实战里都有过案例。既然做安全基线，就按最稳的来。

4.2 操作记录留存：AAA日志和配置变更追踪

说到审计，账号操作记录的留存跟系统日志同等重要。华为VRP平台可以通过配置管理面日志输出，把登录成功、登录失败、配置变更等敏感操作记录下来：

[Device] info-center loghost 192.168.100.50 [Device] quit [Device] aaa [Device-aaa] accounting scheme acct_default [Device-aaa-accounting-acct_default] accounting commands all [Device-aaa-accounting-acct_default] quit [Device-aaa] domain default [Device-aaa-domain-default] accounting scheme acct_default

accounting commands all这个参数是审计命令操作的，它会把用户在设备上执行过的每一条命令都记录并发送到日志服务器。这在等保测评里是个核心检查项。

我当时在整改一台核心交换机时，客户要求能看到“谁在什么时间改了哪条配置”。如果只配了系统日志没有配置命令审计，只能看到登录日志，看不到具体执行的命令。加上accounting commands all之后，日志服务器上就能看到每条CLI操作，这对事后的变更回溯价值非常大。

当然这也会带来一个问题：日志量会成倍增加。尤其是在业务割接或者配置高峰期，每条在设备上敲的命令都会产生一条日志。日志服务器的磁盘容量要提前规划好，建议至少预留半年以上的存储空间，或者配置日志轮转策略。

5. 带宽和资源保护：防止单点故障拖垮整台设备

5.1 CPU与内存阈值告警：在故障发生前收到通知

华为设备在资源保护方面有一套内置的监视机制，但默认的配置并不一定符合你的业务场景。我做基线加固时都会动手配置CPU和内存的告警阈值，避免设备在资源耗尽时才被发现。

[Device] cpu-usage threshold 80 restore 60 [Device] memory-usage threshold 80 restore 60 [Device] set cpu-usage notification enable [Device] set memory-usage notification enable

这段配置的效果是：CPU或内存使用率超过80%时，设备产生告警日志；回落到60%以下时，再产生恢复日志。阈值设多少合适？我在核心设备上一般设80%，接入层设备设90%。设得太低（比如60%）反而容易在业务高峰时产生大量噪声告警。恢复阈值和告警阈值之间要有一定间隔（Hysteresis），否则临界状态下会产生告警抖动。

还有一类资源保护容易被忽视——ARP报文。局域网里出现ARP泛洪时，设备CPU会飙升，转发性能直线下降。华为设备上可以用：

[Device] arp anti-attack rate-limit packet 30

这个命令限制接口每秒处理的最大ARP报文数。限速值不是越小越好，我见过有人限到每秒钟10个包，结果内网电脑一多，ARP表项建不起来，全网掉线。建议从30到50开始调，根据实际终端数量观察一段时间再决定是否收紧。

5.2 接口安全与广播风暴抑制

接口层面的保护也是安全基线的一部分。华为交换机的接口默认情况下允许学习海量MAC地址，如果某个接口被人接了一台设备在上面跑MAC泛洪，CAM表被打满之后，交换机的转发行为会退化到向所有端口广播所有报文，等于直接把自己的内网流量敞开了给别人看。

对应的命令：

[Device-GigabitEthernet0/0/2] port-security enable [Device-GigabitEthernet0/0/2] port-security max-mac-num 5 [Device-GigabitEthernet0/0/2] port-security protect-action shutdown

protect-action shutdown是关键——当接口学习的MAC地址超过5个上限，端口直接error-down。这比只告警不动作的配置要安全得多。当然，如果你的接入场景是一个接口接了一整排傻瓜交换机（这是违规接法，但现实中大量存在），MAC地址上限5个会直接把业务打挂，所以端口安全的配置要结合真实的接入环境来看。

广播风暴抑制同样要防。广播报文在二层网络的传播范围是所有同VLAN接口，一旦出现环路或广播风暴，处理不及时就是全网瘫痪。华为接口下配置风暴控制：

[Device-GigabitEthernet0/0/2] broadcast-suppression 20 [Device-GigabitEthernet0/0/2] multicast-suppression 20

这里的20是百分比，意思是该接口允许通过的广播/组播流量占接口带宽的20%，超过就丢弃。注意这个配置是百分比形式，按接口带宽自动换算，不需要手动计算报文速率。20%这个值比较稳妥，既能保证DHCP、ARP这类基础协议正常工作，又能防止风暴把带宽打满。如果你的终端数量特别多或者网络里有组播业务（比如视频会议），可能要把multicast-suppression放宽一点到30%或40%，但broadcast-suppression不建议超过30%。

6. 华为设备安全基线检查清单与实战流程

6.1 基线检查清单：照着这个逐项过

在多年的安全基线落地过程中，我逐渐积累了一个相对完整的自查清单。它不完全等同于官方文档里的等保检查项，但更贴近实际运维场景。每次给华为设备做基线核查时，我会按下面这个顺序逐项过：

在等保2.0的测评语境下，这个清单基本能覆盖对方会问到的大部分设备侧控制项。每次检查后把对应的命令配置截图留存，方便测评审核时提供证据。

6.2 落地执行流程：从核查到整改再到复测

有了清单之后，执行流程很关键。我的习惯分四步走。

第一步，设备信息收集。登录设备执行display version、display current-configuration这些命令，确认版本和当前配置。VRP平台版本不一样，部分命令的细节会有差异，不能拿一套命令通吃所有设备。

第二步，逐项核查。按清单的检查大类逐项执行检查命令。比如检查当前账号口令策略就执行display password-policy，检查SSH配置就执行display ssh server status、display user-interface vty 0 4。每一分项的结果记录在案，标注出哪些项不达标。

第三步，加固整改。对不达标的项目逐条执行修复命令。这个环节要特别注意变更窗口。生产设备千万不要在业务高峰期直接改配置，尤其是涉及重启的操作，比如undo http server enable这类命令有时候会引起管理面会话短暂中断，要跟业务方提前沟通好窗口。

第四步，复测验证。整改完成后隔一天再登上去重新检查一遍，确认没有配置回退或异常。同时检查一下日志服务器上是否收到了相关变更日志，确保审计链路是通的。

6.3 常见问题的排查思路和避坑经验

做安全基线这么多年，踩过的坑比见过的设备还多。挑几个最典型的分享出来，帮你在实操时少走弯路。

第一个坑是关于SSH配置的。有些华为老版本设备上，启用SSH前必须先生成RSA密钥对，否则后续的SSH连接根本建立不起来，而且报错信息还非常隐晦。配置流程要严格按照“生成密钥对-配置VTY认证-指定protocol inbound ssh-开启SSH服务”的顺序来，少一步都不行：

[Device] rsa local-key-pair create The key name will be: HOSTNAME_Host ... [Device] user-interface vty 0 4 [Device-ui-vty0-4] authentication-mode aaa [Device-ui-vty0-4] protocol inbound ssh [Device-ui-vty0-4] quit [Device] ssh server enable

第二个坑是带宽抑制和端口安全的联调问题。我在一次项目上把接入层交换机的端口配了port-security protect-action shutdown，同时广播抑制设得比较低，结果有两个终端之间在做网络打印机共享时频繁触发端口安全误判，端口不停shutdown，业务方气得跳脚。后来排查发现是那台打印机内部有虚拟化接口，一个物理端口背后其实挂着好几个MAC地址。解决办法是把该端口的max-mac-num从默认值调到10，并且把protect-action从shutdown改成restrict（只丢弃非法报文不关端口），过了一段时间观察稳定后再收紧回来。这里要说明的是，安全基线不是越严格越好，而是要在安全和可用性之间找平衡点。

第三个坑是配置保存。华为设备的配置在用户视图下执行save命令才会写入flash，否则设备重启后所有加固全部失效。这个问题看似基础，但我真在项目上遇到过——同事做完整改后觉得配置已经生效了，没执行save，第二天设备因为停电重启，所有安全配置全部回到出厂状态，等于白干。

第四个坑出在NTP认证上。部分华为老版本对NTP认证的支持有兼容问题，配置后NTP时间同步会失败。如果你配置了NTP认证之后发现时间一直不同步，先用display ntp-service status看同步状态，再用display ntp-service sessions看会话详情，把认证密钥重新配置一遍，注意密钥ID在客户端和服务器端要保持一致。

7. 把安全基线固化到日常运维流程中去

安全基线不只是一次性的整改项目，更应该是设备日常管理的一部分。我自己的做法是，把基线检查项做成一个标准操作脚本，每次新设备上线前，先按清单做完基线加固再交付业务。已经上线的老设备，每季度抽一台出来做一次基线复核，确保没有配置漂移。配合华为的eSight或者第三方网管平台，还可以对设备配置做定期备份和差异比对，配置被改动了系统会自动告警。

有个细节值得单独提出来——基线文档的版本管理。网络环境和业务需求一直在变，安全基线文档也需要跟着迭代。比如你原来关掉了HTTPS管理服务，后来业务方需要通过Web界面查看设备状态，你只能在策略上开一个白名单给特定IP段。这个变更需要记录在基线文档的变更历史里，并说明原因和审批人。如果你不做记录，下次复查的时候会发现设备“不合规”，但实际上这个不合规是业务行为导致的合法变通。

在我处理过的项目里，真正让安全基线产生价值的时刻，往往是出了故障或者出现异常后回溯的时候。比如某天日志服务器收到一条设备告警，有人从外网IP尝试多次SSH登录。因为之前配了登录失败锁定策略，那个IP尝试了5次就被锁住了，日志里清清楚楚记着这个事件。如果没有基线，这种尝试连个水花都看不到。好的安全基线不会总是拦住那些成功的攻击，但它会让每一次失败的尝试都留下清晰的痕迹，这就足以让绝大多数攻击者望而却步了。

最后再分享一点经验：安全基线的本质不是堆配置，而是做减法。把你不需要的端口关掉，把用不上的服务停掉，把没设防的入口都封上，设备的安全水平就已经超过大部分同类环境了。那些复杂的安全策略和高级防护特性，应该是在基础的基线检查做完之后再考虑的事情。我见过不少人一上来就研究各种高级安全特性，结果基础的账号密码和未授权服务都没搞定——这就像门锁都没换，先装了全套监控摄像头，方向完全错了。