Oracle 19c配置密码限制策略防止暴力破解

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

生产环境中一个常见陷阱是：只设置 FAILED_LOGIN_ATTEMPTS，却未同时配置 PASSWORD_LOCK_TIME，导致账户锁定后无法自动解锁。Oracle 默认的 PASSWORD_LOCK_TIME 为 0，并非预期的“1小时”或“1天”。许多DBA在初次接手时容易忽略这一细节，造成运维负担。

FAILED_LOGIN_ATTEMPTS 与 PASSWORD_LOCK_TIME 配对设置

这两个参数必须出现在同一条 ALTER PROFILE 语句中，否则账户被锁后将永久处于锁定状态，无法自动解锁。生产环境下通常需要DBA手动介入才能恢复。以下是关键配置说明：

• FAILED_LOGIN_ATTEMPTS 控制失败次数达到后触发锁定，常见取值为 5 或 10
• PASSWORD_LOCK_TIME 单位为“天”，设为 1/24 表示锁定1小时，1/1440 表示锁定1分钟——分数格式需准确，否则易出错
• 若设为 UNLIMITED，则相当于永久锁定，只能由DBA执行 ALTER USER ... ACCOUNT UNLOCK 才能解锁
• 修改后立即生效，不影响已登录会话，新登录尝试将按照新规则校验，无需重启数据库

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

直接在 DEFAULT profile 中修改 FAILED_LOGIN_ATTEMPTS，将影响所有未显式指定profile的用户（包括 SYS、SYSTEM、DBSNMP），存在误锁风险。例如某次误操作导致监控账号被锁，Zabbix告警全部中断，事后排查发现根源即为修改DEFAULT profile。建议操作流程如下：

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