企业官网建设流程全解析

1. 先聊清楚：为什么光纤交换机的默认密码比普通交换机更要命

很多人第一次接触光纤交换机，是在机房上架环节。设备加电、配管理 IP、插根网线，telnet或者 SSH 连上去，提示符出来，输入admin和password，进去了。搞定，收工，后面的事交给存储工程师。三个月后安全扫描报告出来，一条高危项赫然写着“网络设备存在默认口令”，Owner 一栏填的是你的名字。这种事我见过不止一次，而且每次处理起来都比想象中麻烦，因为光纤交换机不像普通以太网交换机那样随手就能重启、随手就能刷配置，它在生产环境里往往承载着核心业务的主机到存储链路，动一下要做好几层确认。

这篇内容聊的就是博科光纤交换机（Brocade FOS 系统）默认密码的更改。它不是一个“输入两条命令就完事”的操作，而是涉及账号角色体系、密码策略、版本差异、Web 与 CLI 两个入口、以及改密之后如何验证和回滚的一整套流程。适合正在做等保整改、上线安全检查、或者刚接手一套 SAN 环境需要做基础加固的运维人员看。哪怕你之前只接触过 Cisco、华为的以太网交换机，对 FOS 完全陌生，看完也能照着把流程走完，不至于在passwd和userconfig之间来回试。

我先把结论放前面：光纤交换机的默认口令加固，难点从来不在“改密码”这个动作本身，而在于三件事——第一，你得知道这套系统里有几个账号、哪个是真正的高权限；第二，你得清楚当前 FOS 版本对密码复杂度的要求，否则改完自己都登不进去；第三，你得在改之前想好一条退路，因为一旦把 admin 锁死，恢复手段相当有限。下面按我实际操作的顺序往下捋。

2. 动手之前先把账号家底摸清：角色、入口与版本差异

2.1 FOS 里的账号角色与默认账号盘点

博科 FOS 的账号体系和普通交换机不太一样，它不是简单的“管理员/普通用户”两级，而是一套基于角色的访问控制（RBAC）。默认出厂状态下，你能看到的账号通常只有一两个，但实际上系统支持创建的角色有七八种，每种角色的权限边界差别很大。先把这些搞明白，后面改密的时候才不会出现“密码改了但业务登不上”的尴尬。

常见的角色和用途大致是这样：

默认账号这块，不同版本差异很大，但有几个是绕不开的：

• admin：这是最核心的账号，出厂默认密码通常是password。基本所有可管理的 FOS 版本都有这个账号，且不能删除，只能改密。
• root：早期版本默认密码是固定的，后来版本要求首次使用前必须设置或修改。这个账号权限极高，能进底层，一旦泄露等于设备完全失守。
• factory：非常老的版本里有，默认密码也是固定的，新版本基本不再启用，如果userconfig --show -a能看到，建议直接处理掉。
• user：部分版本带一个只读账号，默认口令同样是弱口令，属于扫描器一眼就能命中的目标。

我一般上机第一件事不是急着改密，而是先跑一条命令把现状看清楚：

switch:admin> userconfig --show -a

输出会把所有账号、角色、是否 admin、是否锁定、home 属性都列出来。这一步的价值在于，你能知道这套设备到底有几个“活人”在用的账号，有没有历史遗留的临时账号，有没有本该删掉却一直留着的。我遇到过一台设备，里面同时躺着admin、user、factory和两个带着项目缩写前缀的临时账号，最后一个账号的主人早就离职了。这种情况下你只改admin的密码，等于什么都没做。

2.2 三个登录入口的取舍与前置检查

改密码之前，得先确认你从哪个入口进。博科光纤交换机通常有三个管理入口：串口 Console、SSH/Telnet 命令行、Web Tools 图形界面。三者的能力和适用场景不一样，选错了会走弯路。

串口 Console是最可靠的入口。设备刚上架、管理 IP 还没配、或者网络配置改错了导致 SSH 连不上，都靠它救场。缺点是必须到机房，或者通过终端服务器跳转。我的习惯是：任何涉及账号和密码策略的变更，只要能安排，优先走 Console。原因很现实——改密过程中如果触发账号锁定或者会话超时，SSH 断了就得重新来，而 Console 会话相对稳定，也方便我把整个过程完整记录下来。

SSH是日常最常用的。FOS 对 SSH 的支持比较完整，登录后提示符一般是switch:admin>这种格式。这里有个细节要注意：部分老版本默认只开了 Telnet，SSH 需要手动启用。如果你发现 22 端口不通，先别怀疑网络，可能是服务没开。

Telnet在合规场景下基本应该关掉。明文传输，密码在链路上裸奔，安全扫描一定会报。新一些的 FOS 版本默认就禁用了 Telnet。

Web Tools是图形界面，优点是直观，改密、看 zone、看端口状态都能点出来；缺点是它依赖浏览器和 Java 组件，老版本的 Web Tools 在新版浏览器上经常打不开，兼容性是个坑。真要用，建议用对应版本官方说明里的浏览器组合，别拿最新版 Chrome 硬刚。

前置检查我一般会做这么几项：

• 确认当前登录账号是admin或者带用户管理权限的securityadmin，否则改不了别人的密码。
• 确认设备的配置已经备份过，configupload跑一遍，把配置文件传到一台临时的 FTP/SFTP 服务器上。这一步不是形式主义，改密过程中如果误操作把账号删了，配置文件是最后的救命稻草。
• 确认手上有至少两个可用的高权限账号，或者确认 Console 一定可用。原因后面讲踩坑的时候会细说。
• 记下当前 FOS 版本，version或者firmwareShow都能看。版本直接决定你用哪套密码策略命令。

2.3 版本差异决定操作路径

这一块是新手最容易翻车的地方。FOS 的密码策略命令在 7.x 和 8.x 之间有过一次比较大的调整，用错命令要么报错，要么改了个寂寞。

大致可以这样分：

判断自己该用哪套，最稳妥的办法是先跑passwdcfg --show。如果命令不存在，说明版本较老，退回passwd -a。这两条命令都不会修改任何东西，是安全的探测手段。

还有一个容易忽略的点：有些版本在升级固件之后，密码策略会被重置或者继承旧策略，升级完最好重新show一遍确认。我就吃过这个亏，升级前设好的复杂度要求，升级后回到了默认值，扫描报告又冒出来了。

3. 命令行实操全程：从首次登录到策略真正落地

3.1 首次登录的强制改密与 admin 改密

新设备或者恢复出厂设置的设备，第一次用admin登录时，很多版本会直接弹出一段提示，要求你立刻修改密码，不改就不让进。这个流程是强制的，跟着提示走就行，输入旧密码、新密码、确认新密码三步。

如果没触发强制改密，就手动来：

switch:admin> passwd

系统会先让你输当前密码，然后输两遍新密码。这里有个细节：输入过程中屏幕不回显，别以为键盘坏了。改完之后当前会话一般不会掉，但下次登录就得用新密码了。

给其他账号改密，用带用户名的形式：

switch:admin> passwd user1

需要admin权限。有些版本会要求你先确认目标账号存在，不存在会直接报错。改完可以用userconfig --show -a复核一下，虽然密码本身看不到，但能看到账号状态是否正常。

root账号的处理要单独说。这个账号的密码修改方式和普通账号不太一样，部分版本需要用passwd root，部分版本要求先通过admin授权。我一般的做法是：如果业务上不需要root做底层调试，就把它的密码改成一个足够复杂、单独保管的口令，不发给任何人，只在应急时从密码管理系统里取。千万不要图省事把它设成和admin一样的密码，那等于把两层门合并成一层。

注意：改admin密码之前，务必确认你有第二个可用的高权限账号，或者 Console 一定能连上。某些版本的锁定策略一旦触发，SSH 侧会直接拒绝该账号登录，而解锁又需要另一个 admin 账号操作，形成死循环。

3.2 创建新管理员并回收默认账号

只改默认账号的密码，其实是“打补丁”思路。更彻底的做法是：新建一个命名规范的管理员账号，用它做日常运维，然后把默认的admin密码改成一个超长随机串并封存，或者按版本能力做限制。

创建账号的命令大致是这样：

switch:admin> userconfig --add opsadmin -r admin -h 0 -a 1

参数含义需要解释一下，不然容易填错：

• --add opsadmin：账号名，建议用“岗位+编号”的命名，别用姓名拼音。
• -r admin：角色，这里给的是 admin 角色。
• -h 0：home 属性，0 表示不设置 home 目录，1 表示设置为交换机 home。日常管理账号一般用 0。
• -a 1：是否具备管理员属性，1 为是。

创建过程中会要求输入密码。这里就要和下一节的密码策略对齐了，如果策略要求 12 位且包含四类字符，你在这里输一个 8 位的简单密码，会直接被拒。

账号建好之后，先用新账号登录验证一次，确认权限正常、能执行关键命令，再考虑处理默认账号。这个顺序很重要，先建后废，不能反过来。

处理默认账号有几种做法，按激进程度排：

1. 改密封存：把admin密码改成随机长串，记录在密码管理系统里，只在应急时使用。这是最保守也最通用的做法，因为admin在多数版本里无法删除。
2. 降权：如果版本支持，把admin的角色调整为一个很少用的低权限角色。但要注意，某些系统内部机制依赖这个账号，降权可能影响固件升级等功能。
3. 禁用：少数版本支持禁用账号，但admin通常不允许禁用。

我一般选第一种。理由很实际：光纤交换机的应急场景（比如 zone 配置错乱导致业务中断）需要最快速度拿到最高权限，这时候有一个封存的admin账号比翻找自己建的账号更快。前提是这个密码真的封存好了，不是写在便签上贴在机柜门内侧。

对于那些历史遗留的临时账号，处理方式就简单直接：

switch:admin> userconfig --delete tempuser01

删之前确认这个账号当前没有活跃会话，否则会提示无法删除。可以先看看谁在线：

switch:admin> userconfig --show -a

输出里一般会标注当前登录状态。

3.3 密码策略配置的实际参数怎么定

这一步是整篇内容的核心。很多人改完密码就结束了，但密码策略没配，下次别人建账号照样能设一个12345678，等于白干。

先看当前策略：

switch:admin> passwdcfg --show

输出会列出最低长度、大小写要求、数字要求、特殊字符要求、历史记录数、过期天数、锁定阈值等。FOS 8.x 之后的默认值大致是：最小长度 8，要求至少一个大写、一个小写、一个数字、一个特殊字符，历史记录 5 条。这个默认值放在今天看是偏松的，可以适当收紧。

配置命令的写法：

switch:admin> passwdcfg --set -minlength 12 switch:admin> passwdcfg --set -uppercase 1 switch:admin> passwdcfg --set -lowercase 1 switch:admin> passwdcfg --set -digit 1 switch:admin> passwdcfg --set -punct 1 switch:admin> passwdcfg --set -history 8 switch:admin> passwdcfg --set -expire 90 switch:admin> passwdcfg --set -warn 15 switch:admin> passwdcfg --set -lock 3 switch:admin> passwdcfg --set -unlock 30

这些参数不是拍脑袋定的，背后有实际考量，我逐个说一下我的取舍逻辑。

最小长度定 12 而不是 8。这个可以从组合空间算一下。假设字符集是大小写字母加数字加常见特殊字符，大约 94 个字符。8 位密码的组合空间是 94 的 8 次方，约 6.1×10^15；12 位是 94 的 12 次方，约 4.8×10^23，差了将近 8 个数量级。对于一台管理口暴露在内网的设备来说，这个差距直接决定了暴力破解的可行性。当然，长度上去了，运维人员记不住，所以配套要有密码管理工具，这是另一个话题。

大小写、数字、特殊字符全开。有些单位为了好记，只要求长度不要求复杂度，结果用户全用一句拼音短语。这类密码在字典攻击面前基本没有抵抗力。四类字符全开之后，用户的密码习惯会明显改变。

历史记录定 8。默认 5 意味着改 5 次就能绕回原密码，对于季度改密的场景，一年多就转回来了。定 8 大约能覆盖两年。

过期 90 天、提前 15 天提醒。90 天是等保场景里比较常见的周期。提前 15 天提醒很重要，因为 FOS 的过期提醒只在登录时弹出，如果不提前告知，运维人员某天突然发现登不进去，会非常被动。提醒期太短（比如 3 天）等于没提醒，人一出差就错过了。

锁定 3 次、解锁 30 分钟。这个参数要特别注意。锁定次数设太小，比如 2 次，运维人员手抖输错两次就被锁，体验很差；设太大，比如 10 次，暴力破解窗口又太宽。3 次是比较平衡的值。解锁时间设 30 分钟，意味着锁了之后等半小时自动恢复，不需要人工介入。如果设成 0，就是永久锁定，必须由另一个 admin 手工解锁，这在只有单管理员的场景下是灾难。

这里有个坑必须提醒：-unlock的值在不同版本里含义可能相反。有的版本 0 表示“不自动解锁”，有的版本 0 表示“立即解锁”。配置完一定要实测一次：故意输错密码触发锁定，然后观察是否按预期恢复。我见过一个现场，-unlock填了 0，结果账号被永久锁死，最后靠 Console 加特殊恢复流程才救回来，前后花了两个多小时。

策略改完之后，用一条命令复核：

switch:admin> passwdcfg --show

确认每一项都生效了再往下走。

3.4 保存配置、备份与审计留痕

FOS 的账号和密码策略变更，多数情况下是立即写入的，不像 zone 配置那样需要显式cfgsave。但为了保险，改完之后还是跑一次：

switch:admin> cfgsave

这条命令保存的是当前生效配置，对用户管理这部分是否有影响，不同版本不一样，但执行一次没有坏处。

更重要的是配置备份。改密前后各做一次configupload，把配置文件传到临时的 SFTP 服务器上：

switch:admin> configupload

按提示输入协议、服务器地址、路径、账号密码。备份文件里包含账号信息（密码是加密或哈希形式），所以这个文件本身也要按敏感资料管理，不能随手放在共享盘上。

审计留痕方面，FOS 有审计日志：

switch:admin> auditlog --show

或者用auditdump导出。改密这种操作会在日志里留下记录，包括谁、什么时候、对哪个账号做了什么。等保检查的时候，这份日志是重要的佐证材料。我的习惯是每次变更后把相关时间段导出一份存到变更记录里，和变更单放一起。

4. Web Tools 与集中管理平台：另一条改密路径

4.1 Web Tools 里的两条入口

不是所有人都习惯命令行，Web Tools 提供了图形化的改密入口。大致有两条路径。

第一条是修改当前登录账号自己的密码。登录 Web Tools 之后，页面右上角一般有当前用户名，点开之后能看到 “Change Password” 之类的选项。输入旧密码、新密码、确认，提交即可。这条路径适合个人账号自助改密。

第二条是管理员修改其他账号的密码。进入管理菜单，找到 User Management 或者类似名称的页面，会列出所有账号。选中目标账号，页面上会有修改密码、修改角色、删除等操作按钮。这条路径适合批量维护。

Web Tools 的坑主要在兼容性上。老版本 FOS 配套的 Web Tools 依赖特定版本的 Java 运行环境，浏览器安全策略一升级，页面就白屏或者按钮点不动。我遇到过的典型现象是：页面能打开，账号列表也能看到，但点“修改密码”弹窗出不来，控制台报一串脚本错误。这种时候别浪费时间折腾浏览器设置，直接切回命令行，两分钟搞定。

另外一个细节：Web Tools 的会话超时时间通常比 SSH 短。改密改到一半会话过期，页面跳回登录页，前面的操作白做。所以用 Web Tools 做批量操作时，动作要快，或者提前把超时调长。

4.2 多台设备的批量处理思路

真实环境里很少只有一台光纤交换机。一个中等规模的 SAN 环境，两台核心加几台边缘，七八台是常态。逐台登录改密，效率低还容易漏。

批量处理有几种思路，按门槛从低到高排。

第一种是脚本化 SSH。用 Python 的 paramiko 或者 shell 加 expect，把登录、改密、验证串起来。这种方式灵活，但要注意两个问题：一是首次登录的强制改密流程会打断脚本，得单独处理；二是改密命令的交互提示在不同版本里措辞不同，正则匹配要写宽松一点。我一般会先在一台测试设备上把交互流程录下来，再照着写匹配规则。

第二种是通过集中管理平台。博科有自家的管理平台，能纳管多台设备，做统一的账号策略下发。这类平台的好处是策略一致性好，不会出现这台要求 8 位那台要求 12 位的情况。缺点是平台本身的部署和维护有成本，小环境不一定划算。

第三种是配置模板加批量下发。把密码策略命令写成一个脚本文件，通过自动化工具批量推送到各台设备。这种方式适合策略统一调整的场景，比如全环境从 8 位提升到 12 位。

不管用哪种方式，批量操作前一定要做两件事：一是挑一台非核心设备先试，确认流程走通；二是准备好回滚方案，万一批量执行到一半出错，得能快速恢复。我见过一次批量改密脚本把admin密码改成了一个变量没替换成功的字符串，结果那台设备的管理口彻底进不去，最后靠 Console 恢复出厂才解决，代价是 zone 配置全部重建。

5. 改密之后：验证清单、问题排查与真实踩坑记录

5.1 一份可执行的验证清单

改完密码不等于结束，验证才是。我整理了一份清单，每次做完变更照着过一遍，能挡掉大部分“改完才发现问题”的情况。

重点说两个容易被忽略的：弱密码被拒绝和自动解锁生效。这两个是“策略是否真的落地”的试金石。很多人只看passwdcfg --show的输出，以为配了就生效了，实际上某些版本在特定条件下策略不会立即应用，需要重新登录或者重启管理服务。实测一次最稳妥。

业务未受影响这一项，看起来和改密无关，但实际上有联系。如果改密过程中不小心动了账号角色，而某个自动化巡检脚本用的正是那个账号，脚本就会在后台静默失败，等到第二天发现监控数据断了才回头查，排查成本很高。

5.2 常见问题速查

下面这些是我这些年实际遇到过的问题，按现象、原因、处理方式整理成表，遇到类似情况可以直接对号入座。

其中“只有单管理员且被锁”这一条最凶险。某些版本的锁定是全局的，Console 登录同样被拒。这时候常规手段基本无效，需要走厂商提供的特殊恢复流程，而这个过程通常要求设备重启，重启意味着业务中断。所以前面反复强调：改密前先建好第二个管理员账号，或者确认 Console 可用且不被锁定策略覆盖。

“改密后自动化脚本失败”这一条也值得展开。很多环境里的巡检脚本、备份脚本、监控采集，都是用admin账号硬编码密码连设备。你改了密码，脚本第二天就开始报认证失败，但因为脚本本身有异常捕获，日志里只是一行 warning，很容易被忽略。等发现的时候，可能是某项审计要求提供连续监控数据，结果中间断了几天。解决办法是把凭据从脚本里抽出来，放到统一的凭据管理组件里，改密时只改一处。

5.3 几条踩出来的经验

说几条文档里不会写、但实际很影响效率的经验。

第一条：改密操作尽量安排在业务低峰期，并且提前通知相关方。原因不是改密本身会影响业务，而是改密过程中如果出现意外（比如账号锁定需要恢复），可能需要重启管理服务甚至设备。有过一次我在下午三点改密，触发了一个意料之外的锁定，恢复花了四十分钟，期间存储侧的监控告警响个不停，虽然业务链路没事，但解释成本很高。

第二条：密码本身不要用“符合策略但可预测”的构造。比如Company@2024、Switch#01这类，长度够、字符类型也够，但结构太规律，同一批设备很容易被横向猜出来。我倾向于用密码管理工具生成完全随机的字符串，运维人员不记忆，用的时候从工具里取。这样唯一需要记住的就是密码库的主密码。

第三条：每次变更都留下文字记录，哪怕只是给自己看。记录内容包括：改了什么、为什么改、改之前的策略是什么、改之后是什么、验证结果如何、遇到什么问题怎么解决的。半年后你回头查某台设备为什么登不上，这份记录就是唯一线索。我有一次就是因为没记，把一台设备的策略从 8 位提到了 12 位，结果一台老设备的某个管理组件只支持 8 位密码，配置同步一直失败，查了大半天才定位到。

第四条：不要忽略root和factory这类“非日常”账号。安全扫描器扫的不只是admin。有些扫描规则会专门尝试一批已知的出厂口令，一旦命中就报高危。把这类账号全部处理掉（改密封存或者按版本能力禁用），能减少很多报告条目。

第五条：策略收紧要循序渐进。如果环境里有一批设备当前是 8 位简单密码，你直接一步提到 12 位加四类字符加 90 天过期，运维团队会炸锅，因为所有人同时面临改密压力，而且很多人会在同一天忘记密码。我的做法是先提复杂度和历史记录，跑一个周期让大 家适应，再提长度和过期周期。分两步走，阻力小很多。

6. 密码之外：顺带完成的几项加固与后续衔接

6.1 密码只是入口，配套动作要跟上

把默认密码改掉，解决的只是“已知口令可被直接利用”这一个问题。真正让一台光纤交换机的管理面达到可接受的安全水平，还有几件事值得一起做，反正都上机了，顺手处理掉效率最高。

关闭 Telnet，只留 SSH。命令层面看版本支持情况，一般在管理服务配置里。Telnet 的问题是明文，密码在链路上可以被直接抓取，改再复杂的密码也没意义。这条几乎零成本，收益很高。

限制管理访问来源。FOS 支持配置管理访问的源 IP 限制，把允许登录管理口的地址段收敛到运维网段。这样即使密码泄露，攻击面也小很多。配置的时候注意别把自己的跳板机漏掉，否则配置完当场把自己关在门外。

关闭不用的服务。除了 Telnet，还有一些历史服务（比如某些版本的 HTTP 明文管理、FTP 等），如果不用就关掉。每关一个服务，就少一类潜在的攻击入口。

启用登录告警和日志外送。FOS 的审计日志存在本地，容量有限，滚动之后旧记录就没了。如果条件允许，把日志送到统一的日志平台，改密、登录失败、账号锁定这些事件都能被集中监控。这样异常登录尝试能第一时间发现，而不是等安全扫描报告。

定期复核账号清单。这件事没有技术含量，但最容易出问题。人员流动、项目结束、临时账号忘记清理，这些都会导致账号膨胀。我的习惯是每个季度跑一次userconfig --show -a，把清单导出来，和当前运维人员名单对一遍，对不上的就核实，确认无用就删除。

6.2 和自动化、监控体系的衔接

改密这件事，做完之后还有一个隐性的收尾工作：让周边系统知道新密码。

最典型的是监控系统。很多监控平台通过 SNMP 或者 SSH 采集交换机的端口状态、光功率、温度等指标。如果用 SSH 采集，凭据存在监控平台的配置里，你在这边改了密码，那边就断了。表现是监控面板上这台设备的指标变成灰色或者显示为“无数据”，但告警规则如果没配好，可能不会主动通知你。稳妥的做法是变更前先在监控平台里确认采集方式，如果是凭据采集，把更新凭据的步骤写进变更单，一起做掉。

自动化运维脚本同理。巡检脚本、配置备份脚本、zone 变更脚本，凡是连设备的，都要检查凭据来源。理想状态是凭据集中管理，改一处全生效；现实状态往往是散落在多个脚本里，需要逐个排查。我一般会用关键字在脚本仓库里搜一遍设备地址，把相关脚本列出来，逐个确认。

集中管理平台也要同步。如果环境里用了管理平台纳管设备，平台侧保存的设备凭据需要更新，否则平台会显示设备离线或者采集失败。这一步经常被漏掉，因为平台通常是另一个团队在维护，改密的时候想不到通知他们。

最后是文档。设备台账、运维手册、应急手册里如果记录了账号密码（很多环境确实会记），要同步更新。这里要提醒一句：密码写进文档本身就是个风险点，如果条件允许，文档里只写“密码见密码管理系统，条目编号 XXX”，不写明文。这样文档可以正常流转，密码本身不扩散。

6.3 后续还能怎么扩展

这套流程走通之后，可以往两个方向延伸。

一个方向是标准化。把账号命名规范、密码策略参数、验证清单、回滚步骤固化成一份内部操作规范，新设备上线时直接套用，不用每次重新讨论参数怎么定。规范里把“哪些账号必须存在、哪些必须封存、哪些必须删除”写清楚，减少人为判断的随意性。

另一个方向是自动化。把改密、策略下发、验证这三步串成脚本，配合配置管理工具做定期巡检——不是定期改密，而是定期检查策略是否符合基线，不符合就告警。这样能防止有人手工改回去，也能在固件升级导致策略回退时及时发现。

我自己在实际操作中的体会是，光纤交换机这类设备的管理面加固，难点从来不在单条命令，而在于把“账号、策略、验证、周边系统”这四件事串成一条完整的链路。只做其中一步，剩下的环节迟早会以某种方式找回来——可能是一次扫描报告，可能是一次登录失败，也可能是一次半夜的应急电话。把流程走完整，后面就省心了。