Oracle密码策略配置实战：避免账户永久锁定

先分享一个生产环境中常见的陷阱：如果你只设置了 FAILED_LOGIN_ATTEMPTS，却没有同时配置 PASSWORD_LOCK_TIME，那么账户一旦被锁定，就会陷入永久锁定状态——Oracle 默认的 PASSWORD_LOCK_TIME 是 0，而不是“1小时”或“1天”。许多DBA刚接手时都会在这个细节上栽跟头。

FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 必须成对配置

简而言之，这两个参数必须在同一条 ALTER PROFILE 语句中一起设置，否则后果是：账户被锁后永远等不到自动解锁。在生产环境中，这通常意味着需要半夜手动解锁。下面把关键要点梳理清楚：

• FAILED_LOGIN_ATTEMPTS 决定连续失败多少次后触发锁定，常用值设为 5 或 10
• PASSWORD_LOCK_TIME 的单位是“天”，设置为 1/24 表示锁定 1 小时，1/1440 表示锁定 1 分钟——不要小看这个分数，很多人在第一次配置时会写错
• 如果将 PASSWORD_LOCK_TIME 设为 UNLIMITED，则相当于永久锁定，必须由 DBA 手动执行 ALTER USER ... ACCOUNT UNLOCK 才能恢复
• 修改后立即生效，不影响已登录会话，但新登录尝试将按新规则校验——因此修改后无需重启数据库

避免直接修改 DEFAULT PROFILE，优先创建专用 profile

直接在 DEFAULT profile 上修改 FAILED_LOGIN_ATTEMPTS，相当于给所有未显式指定 profile 的用户（包括 SYS、SYSTEM、DBSNMP）统一加锁。这有多危险？曾有一次误操作导致监控账号被锁，Zabbix 告警全部丢失，事后排查才发现是修改 DEFAULT 所致。因此建议：

• 新建一个专用 profile：CREATE PROFILE app_login_limit LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1/24;
• 绑定前先确认用户当前的 profile：SELECT username, profile FROM dba_users WHERE username = 'APP_USER';
• 绑定命令：ALTER USER app_user PROFILE app_login_limit;
• 注意：profile 名称区分大小写，且长度不能超过 30 个字符——这个细节容易被忽视

验证配置是否生效：查看 dba_users.account_status 并测试登录行为

仅查看 dba_profiles 中的 limit 值并不足够，必须实际测试登录行为。很多DBA改完就以为万事大吉，结果攻击者仍在暴力扫描，才发现策略并未生效。

• 测试前先清空测试账号的锁定状态：ALTER USER testuser ACCOUNT UNLOCK;
• 故意输错密码 5 次（使用 sqlplus 或 JDBC），观察第 6 次是否报 ORA-01017: invalid username/password，再次连接时是否报 ORA-28000: the account is locked
• 查询状态：SELECT username, account_status, lock_date FROM dba_users WHERE username = 'TESTUSER'; —— 看到 LOCKED 或 LOCKED(TIMED) 才算成功
• 关键区分：如果 lock_date 有值，且 account_status 显示 LOCKED(TIMED)，说明 PASSWORD_LOCK_TIME 生效；若显示 LOCKED（不带 TIMED），说明 PASSWORD_LOCK_TIME 为 0 或未设置——这两种状态差异巨大

监听器层面也要封堵暴力入口

数据库层面的 FAILED_LOGIN_ATTEMPTS 只能拦截 SQL 层面的登录，无法阻止直接扫描监听器的攻击。去年就有客户被扫描出 200 多个弱密码账户，根因是监听器暴露在公网，且未做节点校验。

• 编辑 $ORACLE_HOME/network/admin/listener.ora，启用节点验证：VALID_NODE_CHECKING_REGISTRATION_LISTENER = ON
• 限制可注册的 IP：REGISTRATION_INVITED_NODES_LISTENER = (localhost,192.168.10.0/24)
• 重启监听器：lsnrctl reload（无需重启数据库实例）
• 验证是否生效：lsnrctl status 输出中应包含 Security: ON 和 Valid Node Checking: ON

最后值得强调的是：真正的防护效果取决于数据库层和网络层策略是否同时生效。单点配置很容易被绕过，尤其是监听器默认放行所有 IP 这个细节——据我观察，90% 的DBA在首次加固时都会忽略这一步。