如何配置Oracle 19c的密码限制策略以防范暴力破解

FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 必须配对设置在同一条 ALTER PROFILE 语句中，否则账户可能永久锁定；PASSWORD_LOCK_TIME 单位为天，设为1/24表示锁定1小时，未设置时默认为UNLIMITED（永久锁定）。

FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 必须配对设置

只设 failed_login_attempts 不设 password_lock_time，账户会被锁定但永远不解锁——这是生产环境最常踩的坑。oracle 默认 password_lock_time 是 0（即永久锁定），不是“1小时”或“1天”。

• 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 告警全丢。

• 新建 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 在首次加固时会忽略。