华为H3C实战 | 第30章 设备管理安全与等保基线

📚 本系列共 43 篇（第 30 / 43 篇）　·　第四卷 设备与安全篇 —— 路由器与防火墙

← 上一篇：第 29 章 防火墙高级功能 　下一篇：第 31 章 BRAS 定位与组网 →

本章导读：前面几章都在让业务通，这一章反过来问：谁有资格改这台设备、怎么证明他是他、干了什么有没有留痕。本章把等保 2.0 三级的要求逐条翻译成设备命令，最后给一份可勾选的基线清单。

本章结构：

• 30.1 功能原理与业务场景 —— 管理面安全的三层堆叠（管理网段 / ACL 限源 / AAA / 日志+NTP）、从路由器转岗的安全思维差别，以及等保条款到配置项的映射表
• 30.2 华为设备配置详解 —— SSH 替换 Telnet、本地用户与权限分级、AAA 对接 RADIUS/TACACS+、SNMP v2c/v3、日志与 NTP、攻击防范
• 30.3 H3C 设备配置详解 —— H3C 侧对应命令与差异
• 30.4 华为 / H3C 命令对照表
• 30.5 配置验证 —— 账号、权限、日志外发、时钟同步逐项确认
• 30.6 排错与故障树 —— “SSH 登不上"“日志收不到"“时间不对"的定位
• 30.7 等保 2.0 三级基线配置清单 —— 逐条可勾选的落地清单
• 30.8 本章小结

重点提示：要过等保就直接用 30.7 的清单当施工单，一条一条打勾；日常运维先做 30.2 里的"关 Telnet 开 SSH + 一人一账号 + 日志外发 + NTP"四件事，性价比最高。30.1.3 提醒过：只配 ACL 不配 AAA 和日志，查不出是谁干的。 关联章节：命令行视图与用户权限基础见第 1 章；设备基础管理（保存、升级、日志）见第 1 章；ACL 的写法见第 17 章；防火墙上的管理面放行（local 区域）见第 26 章。

30.1 功能原理与业务场景

30.1.1 这功能是干嘛的（通俗版）

前面几章都在讲「怎么让业务通」。这一章讲一个反向的问题：谁有资格改这台设备，怎么证明他是他，他干了什么有没有记录。

用小区物业打比方。一栋楼里有几百户人，最怕的不是门窗不结实，而是物业办公室的钥匙丢了一把，或者保洁阿姨有你家的万能卡。网络设备的安全，本质上是「物业办公室」的安全：

• 别用假锁（Telnet 明文传输）：Telnet 就像用喇叭喊密码，谁路过都能听见。SSH 才是把密码写在信封里、封死了递过去。
• 别用同一把钥匙开所有门（本地单一账号）：所有运维都用 admin/Admin@123，出了事根本查不出是谁。
• 要有访客登记簿（AAA 认证与审计）：谁在几点几分从哪个 IP 登录、改了什么，一笔一笔都要留底。
• 要有监控探头（日志与 NTP）：日志时间必须准，否则「上午十点谁改的」根本没法对账。
• 要有门禁禁区（防攻击、ACL 限制管理面）：重要设备只允许从管理网段访问，公网谁都免谈。

等保 2.0 三级就是国家给这套东西定的「装修标准」。它不是让你买什么设备，而是规定了「设备本身必须配置到什么程度才算合格」。这一章的最后一部分，就是把这些要求逐条翻译成设备命令。

30.1.2 在网络里怎么落地（设计视角）

安全的管理面设计，通常是三层叠加：

 运维人员（办公终端）
        |
        | 1. 带外管理 / 管理网段
        v
+-------+--------+
|  管理网段        |  ← 只用这个网段能访问设备管理面
| 10.200.10.0/24  |
+-------+--------+
        |
        | 2. ACL 限制管理源
        v
+-------+--------+        +----------------+
|  网络设备        |--------| 3. AAA 认证     |  ← RADIUS/TACACS+ 集中认证
|  AR / MSR / FW  |        |  服务器         |
+-------+--------+        +----------------+
        |                        |
        | 4. 日志 / NTP            |
        v                        v
+-------+------------------------+----+
|           日志服务器（Syslog）          |
+---------------------------------------+

四层各管一件事：

这四层里，初学者通常只做第 2 层（配个 ACL），做完就说「设备安全了」。 而等保检查的重点恰恰是第 3 层和第 4 层——这两个才是真正「查得出人」的东西。

适用版本：华为 VRP V200R010 及以上（AR 路由器）与 V500R005 及以上（USG6000E 防火墙）；H3C Comware V7（MSR 路由器与 F1000 防火墙，R0615 及以上）。SSH、AAA、SNMP 的相关命令在两家之间的形状相似但语法不同，请以本章命令对照表为索引。

30.1.3 等保 2.0 三级对网络设备的实际要求

等保 2.0 的安全通用要求里，与网络设备配置直接相关的条款集中在「安全计算环境 - 身份鉴别、访问控制、安全审计」和「安全通信网络 - 通信传输」这几部分。翻译成「设备上要配什么」，就是下面这张表：

这张表就是本章的「地图」。后面每一节都在讲其中一行怎么落地，最后一节（29.7）把它们汇总成一份可勾选的配置清单。

30.2 华为设备配置详解

30.2.1 命令行基础速览

设备管理安全相关的命令族：

30.2.2 完整配置模板（关闭 Telnet、改 SSH、本地 AAA）

这是每台设备上线的第一步必须做的配置，也是等保检查的第一项。

# 第一步：基础标识与远程登录方式（只留 SSH）
system-view
sysname AR-CORE

# 生成 SSH 主机密钥（部分版本需要手工生成）
rsa local-key-pair create

# 开启 SSH 服务
stelnet server enable

# 可选：限制 SSH 服务器允许的算法（算法白名单）
ssh server cipher aes128_ctr aes256_ctr aes192_ctr aes128_gcm aes256_gcm
ssh server hmac sha2_512 sha2_256
ssh server key-exchange dh_group_exchange_sha256 dh_group16_sha512 curve25519_sha256
ssh server publickey ecc rsa_sha2_256 rsa_sha2_512
ssh server dh-exchange min-len 3072

这一组命令已核实（华为 VRP 配置指南「配置SSH服务器」章节原文）。注意我第一轮写的 ssh server secure-algorithms cipher ... 这个命令名是错的，正确是上面五条独立命令：

官方特别提醒：客户端的算法列表必须与服务器一致，「如果不一致，可能会导致登录失败」。所以这组白名单属于「可选加固」——不配也能正常登录，配了却把老客户端支持的算法排除了，反而会登不上。做等保「通信加密」项时配它会加分，但配完必须拿实际客户端验证一次。

# 可选：更改 SSH 服务端口（降低被扫描概率），配完记得同步放通策略
ssh server port 1025

# 第二步：创建本地管理员账号（强口令 + 高权限 + 只允许 SSH）
aaa
 local-user netadmin password cipher Net@dmin2024#HQ
 local-user netadmin privilege level 15
 local-user netadmin service-type ssh
 local-user netadmin description HQ-NET-OPS
 quit

# 第三步：VTY 只允许 SSH，禁止 Telnet 接入
user-interface vty 0 4
 authentication-mode aaa
 protocol inbound ssh
 max-login-attempt 5
 quit

# 第四步：关闭 Telnet 服务端（彻底断开明文入口）
undo telnet server enable
undo telnet ipv6 server enable

为什么一定要 undo telnet server enable？ 因为 protocol inbound ssh 只是「这个 VTY 线不接受 Telnet」，但如果 Telnet 服务本身还开着，其他 VTY 线（比如 vty 5 14）可能仍接受 Telnet 连接。两层都关掉，才是真的断了明文入口。 这是等保检查最常抓的一个问题。

30.2.3 逐行讲解

必须展开讲的三个细节：

第一，password cipher 与 password simple 的区别不是「加不加密传输」，而是「配在配置文件里看不看得见」。 cipher 表示口令以密文形式存储在 display current-configuration 里；simple 表示明文存储。只要用了 simple，任何能拿到配置备份的人都能直接读出口令，这是最典型的低级问题。全部用 cipher，这一点没有例外。

第二，privilege level 14/15 的账号不应该泛滥。 等保的「最小权限」原则要求：日常运维用一个 level 3~5 的账号（能做大部分配置查看和小改），改冗余配置、删账号这类高危操作用 level 15。一个只有 2 个人的网络团队，也至少应该有 2 个账号，而不是共用一个 admin。 因为账号是「谁操作」的唯一证据。

第三，service-type 要精确匹配用途。 一个只用于 SSH 管理的账号，service-type 就只写 ssh，不要写 all。all 意味着这个账号还能用来做 FTP、HTTP 等，扩大了暴露面。

30.2.4 口令复杂度与口令策略（华为）

前面讲了「口令要强」，但问题是：你靠什么保证下次改口令的人会改强？ 靠制度不如靠配置。等保要求的口令复杂度、长度、有效期、失败锁定，应该由设备强制，而不是靠提醒。

华为的口令策略命令是 local-aaa-user password policy，分「管理员」与「接入用户」两套。administrator 这套默认就是开启的，命令依据华为官方《配置本地用户》（https://support.huawei.com/enterprise/zh/doc/EDOC1100277024/df3fb67a ）：

# 进入 AAA 视图，再进入本地管理员口令策略视图
system-view
aaa
 local-aaa-user password policy administrator
  # 密码过期功能与过期天数（缺省 90 天；配 0 表示永不过期，不推荐）
  password expire 90
  # 过期前提醒天数（缺省 30 天）
  password alert before-expire 30
  # 历史密码记录条数（缺省 5 条；配 0 等于关闭历史检测）
  password history record number 5
  quit
 quit

密码最小长度用 set password min-length（缺省 8 位）。登录失败锁定用 local-aaa-user wrong-password 这一组命令：

# 账号锁定：重试间隔、连续失败次数、锁定时长（单位：分钟）
aaa
 local-aaa-user wrong-password retry-interval 5 retry-time 5 block-time 15
 quit

官方缺省值是「重试间隔 5 分钟、连续失败 3 次、锁定 5 分钟」，上例把它收紧成「5 次失败锁 15 分钟」。另外还有一条常被忽略的：user-password complexity-check 控制密码复杂度检查，缺省就是开启的，要求密码至少包含大写字母、小写字母、数字、特殊字符中的两种。

几个参数的含义与等保对应：

有一个必须提醒的出厂陷阱：设备空配置启动时，会自动写入 password expire 0（永不过期）和 password history record number 0（不检查历史密码）。 这两条是出厂配置的一部分，手工删掉或不改，就等于「口令永不过期、改密码可以原样改回来」——等保检查必挂。上线第一件事应该是把这两条改回 90 天和 5 条。

「历史口令」这一条经常被忽略，但它恰恰是「定期改口令」能否真正生效的关键。 没有历史口令限制时，员工改口令的做法是「原口令后面加个 1」，或者「改完立刻改回去」，形式上合规、安全上无效。

另一个现实提醒： 口令策略不要一刀切过猛。设成「20 位、3 天过期、12 次历史」，结果就是所有人把口令写在便签上贴在显示器边框——安全策略逼出了更不安全的行为。等保要求的是「满足要求的合理策略」，不是「越严越好」。

30.2.5 AAA 与 RADIUS 集中认证

本地账号的问题很明显：10 台设备 10 套账号，有人离职要挨个改。AAA 就是把「认证、授权、计费（审计）」搬到集中服务器上。

AAA 三角的含义：

华为配 RADIUS 认证的骨架：

# 配置 RADIUS 服务器模板
radius-server template RADIUS_HQ
 radius-server shared-key cipher RadiusKey@2024
 radius-server authentication 10.200.10.20 1812
 radius-server accounting 10.200.10.20 1813
 radius-server retransmit 3
 quit

# 配置 AAA 认证方案：远程认证 + 本地认证兜底
aaa
 authentication-scheme AUTH_HQ
  authentication-mode radius local
  quit
 authorization-scheme AUTHZ_HQ
  authorization-mode radius local
  quit
 accounting-scheme ACCT_HQ
  accounting-mode radius
  quit

# 配置认证域并绑定到方案
 domain hq.example.com
  authentication-scheme AUTH_HQ
  authorization-scheme AUTHZ_HQ
  accounting-scheme ACCT_HQ
  radius-server RADIUS_HQ
  quit
 quit

最后把 VTY 认证指向这个域：

# VTY 使用 AAA 认证，默认走 hq 域
user-interface vty 0 4
 authentication-mode aaa
 quit
aaa
 default-domain admin hq.example.com
 quit

authentication-mode radius local 里的 local 非常关键。 它表示「RADIUS 服务器连不上时，退回本地认证」。如果没有这个兜底，RADIUS 服务器一宕机，所有设备全部无法登录——这是一起典型的高危设计方案，等保检查不但不表扬，反而会记一条「单点故障」。

TACACS+ 与 RADIUS 的取舍：

等保三级的「安全审计」如果要求「记录每个管理员执行的每条命令」，那 RADIUS 不够，得上 TACACS+。

30.2.6 SNMP：v2c 与 v3 的取舍

SNMP（Simple Network Management Protocol，简单网络管理协议）用于网管系统采集设备状态。

# SNMP v2c：团体名（community）相当于明文口令
snmp-agent
snmp-agent sys-info version v2c
snmp-agent community read cipher ReadOnly@2024
snmp-agent sys-info contact net-ops@example.com
snmp-agent sys-info location HQ-3F-IDC-A01
snmp-agent target-host trap address udp-domain 10.200.10.30 params securityname public v2c

# SNMP v3：基于用户的安全模型，支持认证与加密
snmp-agent
snmp-agent sys-info version v3
snmp-agent usm-user v3 monitor group read-group
snmp-agent group v3 read-group privacy
snmp-agent usm-user v3 monitor authentication-mode sha2-256 cipher AuthPass@2024
snmp-agent usm-user v3 monitor privacy-mode aes128 cipher PrivPass@2024

命令顺序与参数已核实：正确顺序是「先建组 snmp-agent group v3 <组名> privacy，再建用户 snmp-agent usm-user v3 <用户名> <组名> authentication-mode sha <口令> privacy-mode aes128 <口令>」。官方 snmp-agent usm-user 命令参考见 https://support.huawei.com/enterprise/en/doc/DOC1000047414/c85113f8/snmp-agent-usm-user 。组的安全级别决定用户可用的最高安全能力，privacy 表示「认证+加密」，只写 authentication 则只能认证不能加密。

v2c 与 v3 的本质区别是「口令是不是明文」： v2c 的 community 字符串在网络上是明文传输的，抓包就能看到；v3 支持认证（保证消息不被篡改）和加密（保证内容不被窃听）。等保三级要求「远程管理采用加密方式」，所以 SNMP 必须上 v3，v2c 只用于「只读、且限制在管理网段」的场景，而且要定期更换 community。

30.2.7 日志与 NTP

日志是审计的基础，NTP 是日志的基础。

# 配置日志外发到 Syslog 服务器（默认 UDP 514）
info-center enable
info-center loghost 10.200.10.30
info-center loghost 10.200.10.30 channel 2

这组命令已核实（华为 AR 命令参考 info-center loghost 条目原文），完整语法是：

info-center loghost ip-address [ channel { channel-number | channel-name } | facility local-number
  | language language-name | transport { udp | tcp ssl-policy ... }
  | { vpn-instance name | public-net } | local-time | port port-id
  | source-interface { interface-type interface-number | interface-name } ] *

几个要点，都是官方原文里明确的：

1. info-center loghost 直接接服务器 IP 就能发日志，channel 是可选参数，不写也能工作。
2. channel 的用处是「给不同日志服务器分配不同的过滤规则」。官方举例：「向 IP 为 192.168.0.1 的日志主机发送信息采用通道 7，向 192.168.0.2 的日志主机发送信息采用通道 8」。
3. port 参数改目标端口（官方示例 info-center loghost 10.1.1.1 port 6514 channel channel6），默认 514。
4. transport { udp | tcp ssl-policy ... } 支持把日志改用 TCP + SSL 加密传输——等保要求「审计记录传输加密」时，这条就是答案。
5. source-interface 指定发日志的源接口，多出口设备必须配，否则日志服务器按源地址做策略会漏。

所以前面示例里写的 info-center loghost 10.200.10.30 channel 2 语法是合法的，但初学者其实不需要指定 channel，直接 info-center loghost 10.200.10.30 就够用了。

# 配置 NTP 客户端，向靠谱的时间源同步
ntp-service unicast-server 10.200.10.40
ntp-service source-interface Vlanif100

# 手工核对时间是否已同步
display ntp-service status

为什么 NTP 是等保的硬性要求？ 因为「日志的时间戳必须准确」是审计的基本前提。如果设备时间漂了 5 分钟，多台设备之间的日志就对不上，安全事件的时间线完全无法还原。更极端的情况：设备时间跑到了「2024 年」，日志就全部错乱，审计等于没做。

30.2.8 防攻击与登录失败锁定

# ARP 防攻击：检测伪造 ARP 报文并对异常源限速
arp anti-attack check user-bind enable
arp anti-attack rate-limit enable

这一组我查到的资料不足以下结论：arp anti-attack 族命令在交换机（S 系列）上很成熟（如 arp anti-attack rate-limit enable、arp anti-attack check user-bind enable），但在 AR 路由器上的可用性未确认。本书示例写的是交换机侧的常见形态；如果你的设备是 AR 路由器，请先敲 arp anti-attack ? 看当前视图是否有这条命令，没有就说明该产品线不支持。

一个更通用的替代方案是在接入交换机上做 DHCP Snooping + IPSG，把「防 ARP 欺骗」的效果通过绑定表实现，这比在路由器上做 ARP 防攻击更标准（详见交换机章节）。

⚠ 待核实：待核实 AR 系列路由器是否支持 arp anti-attack 命令族，需按具体型号版本确认

# 登录失败锁定：连续失败 N 次后锁定
user-interface vty 0 4
 max-login-attempt 5
 quit

登录失败锁定是防暴力破解的关键。 没有它，一个 6 位纯数字口令在公网上几分钟就能被字典爆破。配了 5 次锁定之后，攻击成本大幅上升。

更彻底的方案是 ACL 限制管理源：

# 只允许管理网段登录 VTY
acl number 2001
 rule 5 permit source 10.200.10.0 0.0.0.255
 rule 10 deny
 quit
user-interface vty 0 4
 acl 2001 inbound
 quit

注意 rule 10 deny 这条：ACL 默认是「不匹配则放行」，所以必须显式加一条 deny 兜底，否则 ACL 等于没配。这是 ACL 应用的通用陷阱。

30.2.9 管理面隔离：最有效也最容易忽略的一层

前面所有命令都是「设备上的配置」。这一节讲的是「网络上的设计」，它比任何一条命令都有效。

管理面隔离的核心思想是：设备的 SSH/SNMP/Syslog 端口，只在一条「运维专用通道」里可达。 具体有三种做法：

对于中小企业，管理 VLAN + ACL 限制管理源是最现实的组合。管理 VLAN 的规划要点：

业务网段：192.168.10.0/24（办公）
管理网段：10.200.10.0/24（所有设备的 Loopback/管理口地址）
运维终端：10.200.10.66（只有这一台能登录所有设备）

三层设备上把所有管理地址都放到 10.200.10.0/24，然后用 ACL 只放行 10.200.10.66。这样即使有人在业务网段扫到了设备的管理 IP，也连不上。

Loopback 接口做管理地址是一个重要的加分项：它不依赖任何物理接口状态，只要设备有到管理网段的路由就能管到，比「用业务接口地址管理」可靠得多。业务口的线被拔了、接口被 down 了，Loopback 照样可达。

# 用 Loopback 接口作为设备管理地址
interface LoopBack0
 ip address 10.200.10.11 255.255.255.0
 quit

# 只允许运维终端登录
acl number 2001
 rule 5 permit source 10.200.10.66 0.0.0.0
 rule 10 deny
 quit
user-interface vty 0 4
 acl 2001 inbound
 quit

但这里有个必须提醒的反面： 管理网段一旦被攻破，所有设备等于一锅端。所以管理网段内部的访问也要最小化——运维终端本身要有终端防护、接入要有认证（802.1X 或准入系统）。管理网段是整个网络的「根证书」，它的安全等级应该高于任何业务网段。

30.3 H3C 设备配置详解

30.3.1 H3C 的 SSH 与本地用户配置

H3C Comware V7 的本地用户体系有一个显著特点：用户分「管理类（class manage）」与「网络接入类（class network）」，用户角色（user-role）取代了权限级别（privilege level）。

# 第一步：开启 SSH 服务
system-view
sysname MSR-CORE

# 生成主机密钥（部分版本需要手工生成）
public-key local create rsa

ssh server enable

# 第二步：创建管理类本地用户，绑定 SSH 服务与用户角色
local-user netadmin class manage
 password simple Net@dmin2024#HQ
 service-type ssh
 authorization-attribute user-role network-admin
 quit

H3C 的密码存储三种写法已核实：password simple <明文>（配置回显明文）、password cipher <密文>、password hash <哈希>。官方登录管理配置指导给出的完整语法是 password [ [ hash ] { cipher | simple } password ]（https://www.h3c.com/en/d_201905/1178250_294551_0.htm ）。生产环境应使用 password hash——它用 SHA-512 加盐存储，连设备自己都无法还原明文；simple 绝不使用；cipher 是可逆加密，能用但弱于 hash。password-control 是独立的全局策略体系，与密码存储方式无关，两者要分别配。

# 第三步：VTY 只允许 SSH
line vty 0 63
 authentication-mode scheme
 protocol inbound ssh
 quit

# 第四步：关闭 Telnet 服务
undo telnet server enable

30.3.2 逐行讲解与 H3C 特有概念

H3C 第一大坑：class manage。 Comware V7 的用户分两类，只有 class manage 的用户才能登录设备做管理，class network 的用户是给「上网认证」用的。不写 class 时默认是 network，建出来的账号根本无法登录，而且不会报错——你只会看到「用户名密码错误」。这是 H3C 新手最经典的卡点。

H3C 第二大坑：user-role 与 privilege level 的混用。 Comware V7 用 user-role（network-admin / network-operator / 自定义角色），V5 用 privilege level。在 V7 设备上敲 privilege level 会提示命令不存在，别以为是命令写错了，是版本模型变了。

30.3.3 H3C 的 RADIUS 与 TACACS+ 配置

# RADIUS 方案：主认证/计费服务器地址与端口（认证 1812、计费 1813）
radius scheme RADIUS_HQ
 primary authentication 10.200.10.20 1812
 primary accounting 10.200.10.20 1813
 key authentication cipher RadiusKey@2024
 key accounting cipher RadiusKey@2024
 user-name-format without-domain
 quit

# 认证域（ISP 域）绑定 RADIUS 方案，并带 local 兜底
domain hq.example.com
 authentication login radius-scheme RADIUS_HQ local
 authorization login radius-scheme RADIUS_HQ local
 accounting login radius-scheme RADIUS_HQ
 quit

# VTY 使用 scheme（AAA）认证
line vty 0 63
 authentication-mode scheme
 user-role network-admin
 quit

TACACS+ 的方案配置：

# TACACS+ 方案：适合要求命令级审计的场景（HWTACACS 认证/授权/计费都用 TCP 49）
hwtacacs scheme TAC_HQ
 primary authentication 10.200.10.21 49
 primary authorization 10.200.10.21 49
 primary accounting 10.200.10.21 49
 key authentication cipher TacKey@2024
 key authorization cipher TacKey@2024
 key accounting cipher TacKey@2024
 user-name-format without-domain
 quit

# 认证域绑定 HWTACACS 方案，带 local 兜底
domain hq.example.com
 authentication login hwtacacs-scheme TAC_HQ local
 authorization login hwtacacs-scheme TAC_HQ local
 accounting login hwtacacs-scheme TAC_HQ
 quit

两条格式细节值得记住：H3C 的 user-name-format without-domain（不带域名发送用户名）是常见的对接要求，RADIUS/HWTACACS 服务器上配的账号格式必须与这一项一致，否则认证永远失败；HWTACACS 的认证、授权、计费都用 TCP 49，这与 RADIUS 用 1812/1813 不同。

authentication login radius-scheme RADIUS_HQ local 里的 local 是兜底，与华为的 radius local 等价。这一条是「服务器挂了还能登录」的生命线，任何配置里都不能漏。

30.3.4 H3C 的 SNMP v3 与日志 NTP

# SNMP v3：用户 + 组 + 认证/加密
snmp-agent
snmp-agent sys-info version v3
snmp-agent group v3 read-group privacy read-view iso
snmp-agent usm-user v3 monitor read-group simple authentication-mode sha256 AuthPass@2024 privacy-mode aes128 PrivPass@2024
snmp-agent target-host trap address udp-domain 10.200.10.30 params securityname monitor v3 privacy

⚠ 待核实：待核实 H3C snmp-agent usm-user v3 的认证/加密参数写法与 snmp-agent group v3 的视图参数，需按版本核对

# 日志外发
info-center enable
info-center loghost 10.200.10.30
info-center source default loghost level informational

# NTP 客户端
ntp-service unicast-server 10.200.10.40
ntp-service source-interface Vlan-interface100

30.3.5 H3C 的 SNMP 与日志 NTP 补充说明

前面给了骨架命令，这里补三个现场必须知道的行为细节：

细节一：snmp-agent community read cipher 里的 cipher 只影响配置文件里的存储形式，不影响网络传输。 这一点非常关键：很多人看到配置里写着 cipher，就以为 SNMP v2c 的团体名在网络上也是加密的。不是的——cipher 只是让 display current-configuration 不显示明文，报文里的 community 依旧是明文。要真正加密，只有升到 SNMP v3。

细节二：SNMP v3 的「视图（view）」决定了这个账号能看什么。 默认的 iso 视图覆盖全部 MIB，如果你的监控系统只需要接口和流量信息，可以限定到 system 和 interfaces 子树，减少信息暴露。这是「最小权限」原则在 SNMP 上的体现。

细节三：日志的 source 命令决定「什么类的日志发往哪个目的地」。 一台设备通常同时有「本地缓冲」和「远程日志服务器」两个目的地，两者的过滤级别可以不同：本地缓冲可以留更详细（级别更低），远程只发关键事件。配置成「全部级别都往外发」，会把日志服务器撑爆，反而淹没了真正重要的告警。

# 本地缓冲留详细日志，远程只发关键级别
info-center source default channel 0 log level informational
info-center source default loghost level notification

⚠ 待核实：待核实 H3C info-center source 的 channel 编号与 loghost 关键字的组合用法，需按版本命令参考确认

30.3.6 H3C 的防攻击与登录锁定

# 登录失败锁定（H3C 在 line 视图下配置）
line vty 0 63
 authentication-mode scheme
 protocol inbound ssh
 quit

# 全局口令控制策略：先开总开关，再逐项开启各子功能
password-control enable
password-control length enable
password-control length 10
password-control composition enable
password-control composition type-number 3 type-length 2
password-control aging enable
password-control aging 90
password-control history enable
password-control history 5
password-control login-attempt 5 exceed lock-time 15

注意 password-control enable 只是总开关，长度/复杂度/有效期/历史这几个子功能各自还有独立的 xxx enable。 只开总开关不开启子项，口令策略等于没配——这是 H3C 上非常容易漏的一层。

这一组 password-control 命令是 H3C 相对华为的一大优势——它把等保要求的「口令长度、复杂度、有效期、失败锁定」全部做成了显式的策略命令，一条条对着等保条款配就行，检查时 display password-control 一目了然。华为上对应的功能分散在 AAA 视图的不同位置，配置起来更零碎。

30.4 华为 / H3C 命令对照表

30.5 配置验证

30.5.1 华为验证命令

第一组：确认 Telnet 已关闭、SSH 已开启。

# 查看 Telnet 服务状态
display telnet server status

# 确认 SSH 服务已使能
display ssh server status

display telnet server status 应当显示 Telnet 服务为 disabled。如果显示 enabled，说明 undo telnet server enable 没生效或配置没保存。

第二组：确认账号与权限。

# 查看本地用户及其权限
display local-user

# 查看带口令策略的用户信息
display aaa local-user

第三组：确认 AAA 与 RADIUS 状态。

# 查看 RADIUS 服务器模板与状态
display radius-server configuration

# 查看 AAA 认证方案
display authentication-scheme

第四组：确认日志与时间。

# 查看日志缓冲与发送配置
display info-center

# 查看 NTP 同步状态
display ntp-service status

display ntp-service status 里的关键字段是 Clock status: synchronized 与 System stratum。如果 Clock status 不是 synchronized，时间就是本地时钟在走，日志时间不可信。

第五组：实际登录测试。 命令行验证不如实际登录一次：

1. 用 SSH 客户端连接设备 → 能连接并登录（验证 SSH 正常）
2. 用 Telnet 客户端连接设备 → 连接被拒绝（验证 Telnet 已关）
3. 故意输错密码 6 次 → 第 6 次之后登录被锁定（验证锁定生效）

第 2 项是最容易被忽略的验证：很多人以为配了 protocol inbound ssh 就等于关了 Telnet，实测才发现还有别的 VTY 线能接受 Telnet。

30.5.2 一个完整的「管理面安全验收入手单」

配置完成后，建议按下面的顺序做一次完整的验收，全部通过才算交付：

第 9 步是最容易被跳过的，也是最打脸的。等保测评师有时会要求「重启设备后再验证一次」，如果配置没保存，重启后所有安全配置消失，之前所有工作白做。「配完 → 保存 → 重启 → 复测」是交付的闭环。

30.5.3 H3C 验证命令

# 查看 SSH 服务状态
display ssh server status

# 查看本地用户与角色
display local-user

# 查看口令控制策略
display password-control

# 查看 RADIUS 方案
display radius scheme

# 查看日志与 NTP
display info-center
display ntp-service status

display password-control 的输出会列出全局口令策略的每一项参数，这是等保检查时最方便亮出的一张「成绩单」。

30.6 排错与故障树

30.6.1 管理面故障树

管理类问题最怕「把自己锁在外面」。下表按「连不上 → 登不进 → 登进去做不了事」三段组织：

30.6.2 「把自己锁在外面」的预防

这是管理面配置里最惨烈的一种事故：改 VTY ACL 时把当前登录的源地址也 deny 了，当场掉线，之后谁都登不上，只能去机房插 Console 线。

三条预防措施：

1. 改 VTY ACL 前，先用 display current-configuration 导出配置到本地，万一锁死还能请人到现场恢复；
2. ACL 里第一条永远 permit 你自己的源地址，确认能登录后再收紧其他人；
3. 配完不立即 save，先退出当前会话重新登录一次，验证新配置没有锁死你，再 save。这一步「先验证后保存」，是所有管理面改动的铁律。

# 改 VTY ACL 前的安全模板：先放行自己
acl number 2001
 rule 1 permit source 10.200.10.66 0.0.0.0
 rule 5 permit source 10.200.10.0 0.0.0.255
 rule 10 deny
 quit

30.6.3 日志收不到的排障路径

日志「配了但收不到」是审计类配置的高频问题，排查路径比想象的长：

第 4 条最容易漏：日志服务器通常放在管理网段，而设备发日志的源地址是业务接口地址，两者之间隔着防火墙。防火墙默认拒绝一切，不放行 UDP 514，日志就永远到不了。而且这个故障毫无提示——设备不会报「日志发送失败」。

第 6 条有一个非常隐蔽的规则：数值越小级别越高。 日志级别从 0（emergency）到 7（debugging），配置成「只发送 level 3 及以上」时，level 4 的登录日志会被过滤掉——而登录日志恰恰是审计最需要的那一类。配日志时一定要确认级别覆盖到登录、配置变更这些关键事件。

30.6.4 一个真实的案例

现象：等保测评前一个月，运维按清单把设备的 Telnet 关掉、开了 SSH。测评当天，测评师用 Telnet 尝试登录其中一台设备，成功登录了，直接给了个不符合项。

排查过程：

1. 登进去 display current-configuration 看 VTY 配置：protocol inbound ssh 配了，undo telnet server enable 也配了；
2. 但再查 display telnet server status，显示 Telnet server: enable；
3. 追查原因：这台设备的配置是从另一台老设备拷贝过来的，拷贝时 telnet server enable 那一行带进来了，运维人员的 undo telnet server enable 是在旧配置里敲的，后来又被整体替换掉了。
4. 更隐蔽的是：这台设备的配置没有保存，重启后一切回到旧配置——但运维以为已经配好了。

教训有两条：

1. 配置的正确性必须用「当前运行状态」验证，不能靠「我记得我配过」。 display telnet server status 才是真相，display current-configuration 只显示「配置里写了什么」。
2. 改完必须保存，保存后必须重启验证。 等保测评前应该做一次「配置保存 + 重启 + 复测」，这是唯一能保证「重启后依然是合格状态」的方法。

30.7 等保 2.0 三级基线配置清单

这一节是本章的「交付物」：把前面所有内容整理成一份可以逐项打勾的清单。建议打印出来，每台设备配完逐项打勾，配完存档。

30.7.1 身份鉴别基线

30.7.2 访问控制基线

30.7.3 安全审计基线

30.7.4 入侵防范与其余基线

30.7.5 清单使用说明

这张清单的使用方法比清单本身更重要，有三条：

1. 逐台设备打勾，不要「抽样相信」。 等保测评是逐台检查的，抽样过了不代表全部过。
2. 打勾要在「验证方法」上打，不是「我配了」上打。 记住 29.6.3 那个案例——配了不等于生效，生效了不等于保存了。
3. 每次变更后重新过一遍清单的关键项（第 1、2、8、13 项）。这四项是最容易被后续配置覆盖掉的：有人为了临时调试开了 HTTP、有人加了宽泛的 ACL、有人改了 VTY 配置。

30.7.6 一份可直接执行的巡检脚本思路

清单是一次性的，巡检是持续的。用脚本把清单变成「每次自动检查」，是最省事的合规方式。下面是脚本应该检查的要点（以华为设备为例，H3C 换 display 命令即可）：

巡检项                          检查命令                          合格判断
---------------------------------------------------------------------
Telnet 是否关闭                 display telnet server status      disabled
SSH 是否开启                    display ssh server status         enabled
VTY 是否只收 SSH                display current-configuration     每行 protocol inbound 均为 ssh
是否有空口令账号                 display local-user               无空口令
SNMP 是否为 v3                  display snmp-agent sys-info      仅 v3
NTP 是否同步                    display ntp-service status       synchronized
日志是否外发                    display info-center              有 loghost 配置
管理源 ACL 是否生效              display acl 2001                 有 permit 与 deny

把这一组命令封装成自动巡检任务，每天跑一次，结果推送到运维群。这样做的好处不只是合规——任何一次误操作导致的配置回退，第二天就会被发现，而不是等到测评当天。

30.8 本章小结

30.8.1 要点清单

• 设备管理安全四层：管理网段隔离 → ACL 限制管理源 → AAA 一人一账号 → 日志 + NTP 审计。
• 关 Telnet 要关两层：protocol inbound ssh（VTY 层）+ undo telnet server enable（服务层）。
• 口令必须 cipher/hash 存储，绝不 simple。
• AAA 三角：认证（你是谁）、授权（能干什么）、计费（干了什么）。
• AAA 认证必须配本地兜底（radius local），否则认证服务器宕机全设备失联。
• RADIUS 与 TACACS+：要命令级审计就上 TACACS+。
• SNMP v2c 的 community 是明文的，等保要求 v3。
• NTP 是审计的前提，时间不对，日志等于废纸。
• 管理面改动铁律：先验证新配置不会锁死自己，再 save。
• H3C 用户必须写 class manage，否则建出无法登录的账号。
• 等保清单要「在验证方法上打勾」，不是「我配了」上打勾。

30.8.2 自测题

1. 为什么配了 protocol inbound ssh 之后 Telnet 还可能能登录？正确做法是什么？
2. AAA 认证方案里的「本地兜底」具体指什么？不配会导致什么严重后果？
3. SNMP v2c 与 v3 相比，本质的安全缺陷是什么？
4. 为什么 NTP 同步是安全审计的硬性前提？
5. 在 H3C 设备上建了一个本地用户，密码绝对正确，但 SSH 始终登录失败，最可能的原因是什么？
6. 改 VTY ACL 时如何避免「把自己锁在外面」？

1. protocol inbound ssh 只控制被配的这个 VTY 线（如 vty 0 4）不接受 Telnet，但 Telnet 服务端本身还开着，其他 VTY 线（如 vty 5 14）仍可能接受 Telnet 连接。正确做法是同时执行 undo telnet server enable 关掉服务端，并用 display telnet server status 验证。
2. 指在认证方案中配置「RADIUS 认证失败或服务器不可达时，退回本地账号认证」，如华为 authentication-mode radius local、H3C authentication default radius-scheme X local。不配的话，一旦认证服务器宕机或网络中断，所有设备都无法登录，会导致全域失联。
3. v2c 的 community 字符串在网络中以明文传输，抓包即可获得，获得后即可读取设备全部 MIB 信息；v3 支持报文认证与加密，能防窃听与篡改。
4. 因为审计要求日志时间戳准确、多设备日志可关联。设备时钟漂移会导致日志时间错乱，无法还原安全事件的时间线，「几点几分谁做了什么」这个基本问题都回答不了，审计失去意义。
5. 最可能是创建用户时没有指定 class manage，默认建成了 class network（网络接入类），管理类登录不认这个账号，表现就是用户名密码错误。
6. 三条：①改前导出当前配置；②ACL 第一条先 permit 自己的源地址；③改完不立即 save，先退出重新登录验证没有锁死自己，确认后再保存。

关于本书：《华为 / H3C 网络设备典型功能配置详解》—— 面向国内高校/企业网络环境， 华为 VRP 与 H3C Comware 双厂商并排配置的实操教材，共 43 章。 全书所有命令尽量有官方出处，查不到的显式标注「待核实」。 返回系列目录