戴尔OS10安全加固实战：管理面、二层防护与基线核查落地

上周帮客户做一批戴尔OS10交换机的安全基线核查，用的还是那套老流程：先批量登进去看配置，再对照等保要求逐项找差距。本以为就是个走流程的活，结果登录第一台设备就发现SSH还开着默认端口、管理口acl没写、SNMP用的是缺省社区串，而且是一整批设备都这样。那一刻我就知道，这份“加固攻略”又得从头写到尾了。

戴尔的OS10，全称Dell EMC Networking OS10，是一套基于Linux内核的企业级网络操作系统，主打开放可编程，支持原生Bash、Python脚本，也有类似传统交换机的命令行分层结构。它和思科IOS、华为VRP最大的区别在于：当你敲完配置，默认是写到running-configuration里，但如果不执行保存操作，设备一重启全部打回原形。这一点听着简单，却是很多人做安全加固时改完没保存、最后白忙一场的根因。

这篇内容不打算只扔命令，我会把OS10安全加固这件事拆开讲：先讲清楚这系统的配置机制，再讲管理面、数据面、协议面、审计面四个维度的加固方法，最后用基线核查的完整落地流程把前后串起来。适合正在做等保整改、护网前自查，或者第一次接触OS10、想在设备上建立一套可复用安全基线的人参考。

1. 先摸清OS10的脾气：配置体系与传统交换机的关键差异

做安全加固，第一步不是急着敲命令，而是搞清楚这台设备听谁的、配置是怎么存的、改错了怎么回滚。OS10在这几个方面和传统交换机差别很大，很多人踩坑都踩在这一步。

1.1 为什么OS10让不少老运维发怵

如果你已经习惯在思科或者华为设备上写命令，第一次登上OS10通常会有两个不适应：

第一，命令层级粗看差不多，但细节完全不同。OS10虽然是命令行分层结构，但很多配置语句和IOS并不通用。比如进入端口配置用的是interface ethernet1/1/1，而不是GigabitEthernet0/1；查看运行配置用的是show running-configuration，不是简写的show run。我第一次从IOS切过来时，手比脑子快，敲了三个Tab都补不出来，才意识到这是另一个物种。

第二，它底层是Linux，意味着系统里有一套完整的shell工具链。默认情况下，OS10允许你通过system bash直接跳进Linux shell，可以看进程、看网络栈、甚至能自己写Python脚本调OpenAPI。这个能力很强大，但同时也意味着，如果管理面的认证和访问控制没做好，攻击者一旦攻破交换机，不只是拿到CLI权限，还可能拿到一个可交互的系统shell。所以OS10的加固，本质上比传统交换机多了一层“主机安全”的考虑。

建议第一次接触OS10的人，先别急着做业务配置，花半小时把show running-configuration、show startup-configuration、write memory这几个基本操作摸熟，再谈加固。设备都操作不顺，写出来的基线也是空中楼阁。

1.2 配置提交与持久化：改错了怎么回滚

OS10的配置生效机制可以分为“立即生效”和“保存持久化”两步。你在configure terminal下改的配置，默认是即时写入内存中的running-configuration的，但如果不主动保存，重启后就丢了。保存命令在OS10里是write memory，或者写成完整形式copy running-configuration startup-configuration。

这里有个非常关键的实践点：OS10的配置提交可以做差异化回滚。就是说，你不一定非要凭记忆去删配置，可以先把改动前的running-configuration备份出来，再去做加固变更。如果后续发现配置有问题，直接对比备份文件，把差异部分逐条改回即可。实际操作中我习惯用TFTP或者SCP把原始配置拉到本地，文件名按“设备号+日期”命名，保存至少两份。

另外，OS10还支持配置回滚点，类似快照的思路。在版本较新的OS10上，可以通过配置文件管理功能在写入前自动生成备份，但不同版本命令略有差异，所以最稳妥的做法还是自己手动备份。安全加固最怕的就是改K了，别的都白搭。

我把几个最常见的操作命令整理成了对照表，方便老手快速适应：

表格看着简单，但每一条都对应着一次“手滑敲错”的机会。尤其是show run所有IOS运维都刻在肌肉记忆里了，刚到OS10上会不断打错。我的习惯是给自己一周的适应期，重要操作前先敲？看命令提示，而不是凭肌肉记忆盲打。

2. 管理面加固：把设备入口锁到最小

交换机的管理通道是最容易被外部攻击的入口。OS10默认开放了SSH、HTTPS、HTTP、SNMP、Telnet等多个管理服务，如果不对这些入口做最小化控制，设备基本等于裸奔在网络上。管理面加固我做四件事：管账号、管登录方式、管访问来源、管服务开关。

2.1 账号密码策略：默认账号和弱密码是第一颗雷

戴尔OS10设备出厂时的默认管理员账号通常是admin，部分旧版本默认密码是admin，新版本要求首次登录修改，但如果通过带外管理或者厂家预配置，很容易留下默认密码。等保核查里最容易被直接判不合规的一项，就是设备存在弱口令或默认口令。

账号密码加固的做法分两步：

第一步，关闭或禁用不使用的默认账号。如果设备上存在用不上的内置管理账号，直接进入配置模式禁用，别留着当后门。

OS10(config)# user admin disable

第二步，为需要保留的账号设置强密码策略，并在设备本地开启密码复杂度校验。OS10支持配置最小长度、字符组合要求，命令大致如下：

OS10(config)# system-password complexity enable OS10(config)# system-password minimum-length 12 OS10(config)# system-password minimum uppercase 1 OS10(config)# system-password minimum lowercase 1 OS10(config)# system-password minimum numeric 1

登录超时和失败锁定也要一并设置。网络设备管理口长期挂着空闲会话，看着没什么，实际上等于给别人留了一扇开着的门。我一般把空闲超时调到10分钟以内，连续失败次数超过3次锁定5分钟。

OS10(config)# system login timeout 10 OS10(config)# system login failed threshold 3

2.2 SSH算法收紧与密码登录限制

现在应该没有任何理由再用Telnet管理交换机了。OS10默认SSH是关闭的，需要手动启用，这一步很多人会忘。启用后还要做两件事：第一，关闭密码登录改用密钥认证（如果运维团队具备条件的话）；第二，把SSH算法收紧到目前主流的强加密套件。

先看SSH是否启用以及用了哪些算法：

OS10# show ip ssh

如果看到允许了比较弱的KEX算法或者CBC模式的加密算法，需要显式收紧：

OS10(config)# ip ssh server enable OS10(config)# ip ssh server algorithms encryption aes256-ctr aes128-ctr chacha20-poly1305 OS10(config)# ip ssh server algorithms mac hmac-sha2-512 hmac-sha2-256 OS10(config)# ip ssh server algorithms kex ecdh-sha2-nistp256

严格的生产环境，我建议直接禁用密码登录，只用密钥。OS10支持把SSH验证方式调整为publickey优先，这样即使账号口令被撞库，没有私钥也登不进来。

提示：SSH算法调整前必须确认你的运维终端支持对应算法。很多老版本SecureCRT和某些Linux发行版里较老的OpenSSH客户端，对新算法列表会直接罢工。我吃过一次亏：把算法收紧后发现自己本机登不上去了，最后还是通过带外口进去把算法临时放宽才恢复。正经做法是先改一台终端验证，再批量下发。

2.3 管理ACL：只让运维网段进门

管理面加固性价比最高的一项，就是给管理通道加ACL限制来源地址。OS10里有专门的管理访问列表机制，可以针对SSH、HTTPS、SNMP等管理服务统一限定源网段。我通常会在设备上建一个标准ACL，只放行堡垒机或运维跳板机的网段，其他地址一律拒绝。

OS10(config)# ip access-list standard MGMT-ACL OS10(config-acl)# permit 10.96.10.0/24 OS10(config-acl)# deny any OS10(config-acl)# exit OS10(config)# management access-list MGMT-ACL

加了这条之后，即使账号密码泄露，攻击者也得先过了ACL这道闸才能碰到SSH端口。这是成本最低、收益最高的一道防线，不管设备在核心还是接入层，都应该配上。

这里补充一个容易被忽略的细节：管理ACL不仅管SSH和HTTPS，要确认它把SNMP、NTP等服务的来源也覆盖进去。SNMP虽然看起来只是监控用的，但很多攻击者会拿它做信息收集，读一下sysName、sysLocation、路由表，设备指纹就摸清了。所以SNMP的来源限制和管理ACL最好是一体的。

2.4 关闭清退不必要的管理服务

OS10默认会开启一堆管理服务，包括HTTP、HTTPS、Telnet、SNMP、FTP等。安全基线里有一个铁律：用不到的服务全部关。尤其是HTTP和Telnet，明文协议在管理通道上是绝对的红线。

OS10(config)# no http server OS10(config)# no telnet server enable

如果确实需要图形界面管理，只保留HTTPS，并且后续也建议通过ACL限制来源。至于SNMP，如果监控系统还没接，或者暂时不需要，也先关掉，等需要时再开。

提示：OS10的Web管理界面在部分版本是通过web-management系列命令控制的，不同版本关键字不同。操作前先用show running-configuration | grep -i http之类的命令看一下当前开了哪些服务，再逐个关，别凭记忆把事情做错。服务面最小化做到位，后续发现异常流量的排查面会小很多。

3. 接入层的二层安全防护：防的不是入侵，是内部攻击扩散

管理面加固解决的是“从外面进来”的问题，但做过护网的人都明白，真正的麻烦往往从内部开始：有人插了一台陌生设备、公司内部出现DHCP欺骗、某个端口接到了一台私接路由。二层安全防护的价值就在这里——它防的不是传统意义上的入侵，而是攻击在内部的横向移动。

3.1 DHCP Snooping与动态ARP检测必须成对出现

接入层交换机最典型的攻击场景有两种：一种是攻击者私接一台DHCP服务器，给同网段用户分配恶意网关或DNS，把流量引到自己的机器上；另一种是伪造ARP报文，宣称自己就是网关IP，实现中间人劫持。单纯靠人工排查很难抓到，必须从二层设备层面做防护。

DHCP Snooping的原理并不复杂，它把端口分成信任端口和非信任端口：信任端口通常连接上联交换机或DHCP服务器，允许接收DHCP Offer等消息；非信任端口是接普通终端的，交换机只允许它发DHCP Discover，收到任何DHCP Offer或DHCP Ack响应都直接丢弃。这样一来，私接的假DHCP服务器发的Offer根本到不了用户终端。

DAI的机制则是在ARP协议层面做过滤，交换机通过DHCP Snooping建立的IP-MAC绑定表来校验每一条ARP报文，如果报文的IP-MAC映射不在绑定表里，直接丢弃。

在OS10上，先开DHCP Snooping再开DAI，顺序很重要：

OS10(config)# ip dhcp snooping OS10(config)# ip dhcp snooping vlan 10,20,30 OS10(config)# interface ethernet1/1/49 OS10(config-if)# ip dhcp snooping trust OS10(config-if)# exit OS10(config)# ip arp inspection OS10(config)# ip arp inspection vlan 10,20,30 OS10(config)# ip arp inspection validate src-mac dst-mac ip

这里有一个必须提醒的坑：如果你的接入交换机上存在静态IP设备，比如打印机、服务器、部分摄像头，这些设备的IP-MAC不在DHCP Snooping表里，DAI会直接把它发出去的ARP报文丢掉，导致设备“上不了网”。我处理过太多类似的故障，最后查下来都是DAI误伤静态IP终端。

稳妥的做法是：在启用DAI之前，先用一段时间的DHCP Snooping学习IP-MAC绑定表，导出核对一遍，把静态IP设备单独加到白名单里，或者给对应端口配置静态绑定，然后再打开DAI校验。生产环境千万别把这两个功能一次性全量开，一定是在测试交换机上验证没问题后分VLAN灰度放量。

3.2 端口安全与STP BPDU Guard：接入区腹地封锁

接入层端口最大的问题就是“插上就能用”。端口安全这个老功能至今仍然有效，核心作用有两个：限制端口能学到的MAC地址数量，限制未经授权的MAC地址接入。

在OS10上，接入端口通常这样配置：

OS10(config)# interface ethernet1/1/1 OS10(config-if)# port-security OS10(config-if)# port-security maximum 2 OS10(config-if)# port-security violation shutdown OS10(config-if)# port-security mac-address sticky

解释一下：maximum 2表示这个端口最多学习两个MAC地址，适合接一台PC加一台IP电话的场景；violation shutdown表示超出的MAC地址直接触发端口关闭，而不是仅仅丢弃报文。端口shutdown之后，需要手动no shutdown恢复，让管理员介入处理，而不是让攻击者换个MAC继续试。

如果办公室有访客临时接入的需求，可以单独划分一个Guest VLAN，那个VLAN下关掉端口安全或者把阈值调大，避免员工正常使用被误伤。

STP BPDU Guard是另一道重要防线，专门对付有人私接交换机。正常情况下接入端口不应该收到任何STP BPDU报文，如果收到了，说明有人接了一台交换机，形成潜在的二层环路风险。在接入端口上开启BPDU Guard后，一旦收到BPDU报文，端口会直接进入error-disable状态。

OS10(config)# interface ethernet1/1/1 OS10(config-if)# spanning-tree bpduguard enable

接入层端口全部开启BPDU Guard，是我对每一台接入交换机的强制要求。它不需要依赖任何外部系统，纯本地防护，效果极好。

3.3 风暴控制：坏终端也能拖垮整个VLAN

广播风暴的根源不一定是恶意攻击，一台网卡故障的终端、一个错误的环路、一个陷入死循环的软件，都可能让广播流量在几分钟内打满带宽。风暴控制在OS10上可以按广播、组播、未知单播三种类型分别设置阈值。

OS10(config)# interface ethernet1/1/1 OS10(config-if)# storm-control broadcast level 5 OS10(config-if)# storm-control multicast level 10 OS10(config-if)# storm-control unicast level 30

这里的level是一个近似百分比。接入层终端的广播流量占比通常很低，设为5%比较合适；组播和未知单播可以稍微宽松一些，但也不建议超过20%-30%。阈值设太紧，正常业务可能被误伤；设太松，等于没防护。

特别提醒一点：风暴控制的阈值和端口带宽有关，千兆口和万兆口上同样的数值，实际触发的流量大小完全不同。如果你用的是万兆下联口做服务器接入，最好根据历史正常流量重新评估阈值，别直接抄千兆口的配置。

4. 容易被忽视的服务面收紧：SNMP、NTP、LLDP与未用端口

管理面和数据面加固做完，很多人的核查就结束了。但实际上还有一层容易被忽视的服务面，它不起眼，却常常是审计里被挑毛病的地方。

4.1 SNMP：默认社区字符串是递给攻击者的钥匙

SNMPv1/v2c本身不加密，社区字符串就是唯一的“密码”，而且很多设备初始配置里用的是public/private这种缺省值。OS10也不例外，如果不主动修改，设备上的SNMP默认配置可能维持着非常危险的水平。

正确做法分三步：第一，尽量升级到SNMPv3使用认证和加密；第二，如果监控系统只支持v2c，就用高强度随机字符串作为社区字符串，不要用public/private/switch这类常见词；第三，把SNMP只读权限和写权限分开，生产环境绝大多数只需要只读权限。

OS10(config)# snmp-server community ro "ks#8f9d2!zv3q" restricted OS10(config)# snmp-server host 10.96.10.20 traps version 3 authpriv monitor

在OS10上，restricted关键字的作用是限制该社区字符串的访问来源，具体可以结合ACL使用。审计时如果发现SNMP还开着v1/v2c并且用的是默认字符串，几乎一查一个准。你的监控系统可能只用了几条简单的OID，但攻击者拿到社区字符串后能读取整个设备的运行状态和配置摘要，这等于把设备底裤给别人看了。

4.2 LLDP和未用管理协议：信息泄露的隐门

LLDP是网络设备之间交换链路信息的协议，主要用于拓扑发现。运维角度它很有用，但安全角度它同样会把设备型号、端口标识、系统名称、管理地址送给同一链路里的任何人。对于接入层设备面临的威胁模型，这些信息是不该暴露的。

我建议在接入端口上关闭LLDP，只保留上联端口开启，甚至可以直接全局关掉。OS10关闭方式比较简单：

OS10(config)# no lldp enable

如果部分端口还需要LLDP做拓扑发现，就全局开着，在不需要的接入端口上单独no lldp transmit/receive。这里的原则很明确：设备对外暴露的信息越多，被精准定向攻击的概率就越大。

同理，还要检查设备是否开启了其他不必要的协议，例如FTP server、TFTP server、HTTP server。一个简单的检查思路是：show running-configuration里找出所有带server/service/listen的关键字，逐个确认还有没有存在的必要，发现没有业务依赖的直接关。

4.3 NTP看似无关安全，审计却离不开它

很多做安全加固的人会忽略NTP，认为它只是对时。但等保核查里有一条很明确——设备应配置可靠的时间同步。更深一层，如果设备日志里的时间戳不准，事后追溯攻击路径时根本没法把多个设备的事件串起来，安全日志等于白记。

OS10配置NTP很简单：

OS10(config)# ntp server 10.96.10.130 OS10(config)# ntp source 10.96.10.5

配置完了验证一下同步状态：

OS10# show ntp status

这里要提醒的是：NTP服务器本身也可能成为攻击目标。如果有可能，尽量支持NTP认证，或者至少从管理网段指定NTP服务器，别随便指向公网NTP池，毕竟公网NTP服务器的可用性、安全性都不受你控制。还有一个细节：如果有多个管理VLAN或VRF，确认NTP报文的source地址选择正确，否则回包路径不对，同步永远不成功。

5. 日志与审计面：安全加固最后一块拼图

很多设备加固做完了，却发现遇到安全事件时什么都查不了，原因就一个：日志没留存。安全加固不只是让设备“防住攻击”，还要让设备在发生攻击后能“讲清楚发生了什么”。审计面是整个加固体系的兜底。

5.1 本地日志和远程Syslog必须同时配置

OS10默认会把日志写到本地缓冲，但缓冲容量有限，设备重启后日志会丢。合规的做法是配置远程syslog服务器，把日志实时推送到集中日志平台。

先看当前日志配置：

OS10# show logging

确认本地缓冲开启，再配置远程syslog：

OS10(config)# logging on OS10(config)# logging syslog-server 10.96.10.140

如果不同模块的日志优先级不同，可以分开配置：

OS10(config)# logging syslog-server 10.96.10.140 level informational

这样设置之后，所有info级别及以上的日志都会推送到日志服务器。如果日志平台支持按设备分类入库，记得在syslog配置里带上设备标识，不然后续检索时几十台设备混在一起，对比起来特别痛苦。

5.2 日志分级、时间戳与关键告警门限

日志级别设置太泛会浪费存储，太窄又会漏掉关键信息。我的建议是：安全相关模块全部开到informational，包括AAA认证、配置变更、接口状态变化、STP事件、端口安全事件；转发面里那些高频的debug级别就别开了，否则系统负载上不去。

时间戳是日志里最容易被忽略的细节。如果设备没配置正确的时区和夏令时，日志里的事件时间和实际时间可能差好几个小时，事后分析会被这个时间差坑到怀疑人生。OS10可用以下方式确认时间正确性：

OS10# show clock

再配合NTP同步，确保设备、NTP服务器、日志平台三方时间基准一致。日志平台本身也要启NTP，不然终端时间一致而平台不一致，还是白搭。

端口安全事件和登录失败告警这类日志，建议在日志平台上单独拉一个告警通道。平时不觉得，真到出事的时候，这几条告警就是最快的定位线索。比如端口安全触发shutdown，日志里会明确记录违规MAC地址和端口号，直接顺藤摸瓜找到是哪台设备接入了非法终端。

5.3 审计记录：登录行为和配置变更一个都不能少

OS10默认会记录CLI操作和登录事件，但需要确认这些日志真的被保存下来。等保测评里经常要求提供“网络设备日志留存至少六个月以上”，这个要求单靠设备本地存储是做不到的，必须依赖远程syslog归档。

我在核查时一定会确认三件事：第一，AAA认证日志是否记录了下发账号的操作时间；第二，配置变更操作是否在syslog服务器里有连续记录；第三，设备管理员执行过的命令是否有迹可循。如果追求更强审计能力，可以开启OS10的配置审计标记，具体命令不同版本有差异，但核心思路是一致的：所有写操作都要留痕。

提示：如果现场条件不具备集中日志平台，至少要在设备本地把logging缓冲调大，并且在每次变更前后手动备份配置和日志。虽然没有远程日志审计严谨，但好过什么都没有。别等到事后被问“当时谁改了什么”才意识到日志根本不存在。

6. 基线核查落地流程：从采集现状到整改验证

配置思路都清楚了，最后一步是把“安全加固”真正落到一批设备上。这一步我更愿意把它叫做基线核查落地，因为它不是一个一次性动作，而是“采集现状—对比基线—分级整改—验证回滚”的完整闭环。

6.1 采集现状：先摸清每台设备的家底

核查的第一步是采集每台设备的现状信息。我习惯用一组固定命令把设备的基础信息整理成清单，比如：

• 设备型号和OS10版本：show version
• 运行配置：show running-configuration
• 当前设备资源状态：show system status
• SSH状态和算法：show ip ssh
• SNMP配置：show snmp-server
• NTP状态：show ntp status
• 日志配置与当前缓冲：show logging
• 管理ACL：show running-configuration | grep management

采集过程建议用脚本批量执行，避免手动登一台抄一台的低效。OS10本身支持Python脚本，可以通过SSH批量拉取配置，也可以借助现成的自动化工具。没有自动化条件的，至少写好Shell脚本循环登入，把输出按设备名归档。这一步做好了，后面所有差距分析才有数据基础。

6.2 差距分析与分级整改：紧急项、重要项、建议项

拿到现状数据后，对照基线逐项打勾，差异部分按风险分级。我一般会做成这样的表格：

紧急项意思很明确：涉及设备当前能否被直接攻破，比如弱口令、管理ACL缺失、SSH弱算法。这些必须在当天处理完。重要项是在攻击链路上起作用的防护项，比如DHCP Snooping、DAI、BPDU Guard，可以安排在用维护窗口做。建议项通常不影响直接安全，比如LLDP关闭，可以随日常变更随手处理。

6.3 灰度变更与业务验证：先试点、再分批、留回滚

批量加固最容易翻车的方式，就是一股脑把所有设备全改一遍。设备数量一大，总有那么几台配置特殊：有的跑着老版本OS10，命令语法和当前版本不同；有的下联设备是特殊终端，DAI一开就炸；有的业务用了私有协议，风暴控制阈值稍紧就误伤。这些只有实际操作时才会暴露。

我的执行顺序是：找一台最典型的接入交换机做试点，把全部改动做完，包含配置保存，然后观察一个业务周期，确认没告警、没投诉、日志正常，才扩大到同一个型号的小批量设备。每完成一批，执行diff对比变更前后配置，导出一份变更报告留档。

变更窗口执行时的固定动作我列一下，照着做基本不会漏：先备份原配置，再做加固变更，保存配置，验证管理通道可用，观察业务流量和日志，记录变更前后差异。如果验证阶段发现严重异常，直接回滚到备份配置，事后再排查原因。

提示：部分OS10版本的命令在保存时会对配置做解析校验，直接报错的配置说明当前版本不支持。出现这种情况不要硬扛，先查这台设备的OS10版本号，再确认正确的命令写法。我在现场遇到过同一批设备存在两个大版本的情况，同一个DHCP Snooping配置在一台能敲进去、另一台直接语法错误。所以，统一样本很重要。

最后说点我个人的习惯。做这些安全加固，我从来不会只依赖一份检查表，因为设备到了现场总有超出预期的变化。真正起作用的是“每台设备都按同样的流程走一遍、每一步都留档”这个笨办法。如果你现在手里正有一批OS10要做整改，建议先从一台设备把整条链路跑通，再批量复制。先把SSH算法、管理ACL、账号策略这三项改掉，设备管理入口就安全了大半；再花一个维护窗口把二层防护和服务面收紧做完；最后把日志和NTP调通收尾。整个过程不必追求一天做完，但每一步都要能随时回退。网络安全加固也不例外。