账户锁定策略核心是阈值、时间窗口与状态干预三者协同：Windows建议设阈值5次、锁定及重置计数器均为30分钟；Linux用pam_faillock.so配deny=5、fail_interval=60、unlock_time=900；Web层需独立加固，如Redis按用户名计数并5分钟过期。
配置复杂的账户锁定策略，核心是让系统在检测到异常登录行为时能及时响应、精准限制、可控恢复，而不是简单设个“输错5次就锁”。关键在于三个维度协同：阈值设定要合理、时间窗口要可调、锁定状态要可观测可干预。
Windows 系统：用本地安全策略或组策略精细控制
适用于所有 Windows 11/10 专业版及以上版本。家庭版只能用 secpol.msc（本地安全策略），专业版起可用 gpedit.msc（组策略编辑器）获得更完整支持。
- 账户锁定阈值建议设为 5 次——足够拦截自动化脚本，又避免用户偶尔手误被锁
- 账户锁定时间设为 30 分钟，不是永久锁定，防止管理员误操作后无法登录
- 重置账户锁定计数器也设为 30 分钟，确保“30 分钟内累计错 5 次才触发”，而非跨天累计
- 专业版用户可额外启用 允许管理员帐户锁定，解除 Administrator 账户默认豁免限制
- 若需批量部署，可用 PowerShell 执行
net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:30
Linux 系统：靠 pam_faillock.so 实现可审计的失败计数
主流发行版（Ubuntu 22.04+、Debian 12、RHEL 8+、CentOS Stream）均默认支持 pam_faillock.so，不依赖服务重启，规则生效即刻起效。
- 在 /etc/pam.d/common-auth（Debian/Ubuntu）或 /etc/pam.d/system-auth（RHEL/CentOS）开头插入三行 auth 规则，顺序不可调换
- 典型参数：
deny=5 unlock_time=900 fail_interval=60表示 60 秒内输错 5 次，锁定 15 分钟 - 锁定后用户仍可登录 SSH，但会提示“Account locked due to 5 failed logins”，不会暴露密码是否正确
- 用 faillock --user username 查看失败记录，含 IP、时间戳；用 --reset 或 --unlock 手动干预
应用层加固：Web 登录接口必须独立加锁
操作系统级锁定无法覆盖 Web 应用本身——比如一个 Flask 或 Spring Boot 登录页，攻击者绕过系统登录直打接口，必须单独防护。
- 推荐组合：Redis + 用户名维度计数，key 格式统一为
login_fail:{username} - 每次失败执行
INCR并立刻EXPIRE 300（5 分钟过期），避免计数永久滞留 - 达到阈值后，跳过密码校验直接返回错误，既防暴力也防时序攻击
- Django 用户慎用默认 axes 配置，务必开启
AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP，并确认已运行迁移
验证与运维要点
策略配完不测试，等于没配。尤其注意两类风险点：
- 测试时用非管理员账户操作，避免自己被锁在系统外
- SSH 登录场景下，先开一个保底会话再测试，防止网络中断导致连接丢失
- 定期检查日志：
journalctl -u ssh | grep "Failed password"（Linux）、Windows 安全日志事件 ID 4625 - 对长期不用的账户，建议配合
chage --expiredate 1或usermod -L临时禁用，而非仅靠失败锁定
