首先，你的问题确实是**Geoserver自带的暴力攻击防护机制（BruteForceProtectionFilter）**触发了——这个组件会跟踪IP的请求失败次数，超过阈值就会临时锁定该IP，导致所有请求都返回403，哪怕是管理员登录。重启EC2没用是因为锁定记录存在Geoserver的持久化配置文件里，重启不会清除。

下面是针对你的Amazon Linux + Tomcat9 + Geoserver2.11.2环境的具体解决步骤：

步骤1：停止Tomcat服务 #

首先必须停止Tomcat，避免修改配置文件时出现冲突：

# 用systemd管理的Tomcat（Amazon Linux 2及以上常用）
sudo systemctl stop tomcat

# 如果是旧版用service命令
# sudo service tomcat stop

步骤2：定位Geoserver的Data目录 #

Geoserver的所有配置（包括防护锁定记录）都存在它的Data目录里。默认情况下，这个目录在Tomcat的webapps下，你可以用find命令快速定位：

find /var/lib/tomcat -name "data" -type d | grep geoserver

输出类似/var/lib/tomcat/webapps/geoserver/data，这就是你的目标路径。

步骤3：清除锁定记录或临时关闭防护 #

进入Data目录下的security子目录：

cd /path/to/geoserver/data/security

找到bruteforce.properties文件，这个文件里记录了被锁定的IP和对应的请求计数（比如10.0.0.5=138）。

方案A：清除当前IP的锁定记录 #

直接编辑这个文件，删除包含你服务器/客户端IP的行，或者把计数改成0。保存文件即可。

方案B：临时禁用暴力防护（更彻底） #

如果不确定IP或者想彻底解除限制，可以在文件末尾添加一行：

enabled=false

这样会直接关闭BruteForceProtectionFilter，之后你就能正常登录Geoserver管理界面了（后续记得重新开启）。

步骤4：修复权限并重启Tomcat #

修改完文件后，确保Tomcat用户拥有该文件的读写权限（避免启动报错）：

sudo chown -R tomcat:tomcat /path/to/geoserver/data

然后重启Tomcat：

sudo systemctl start tomcat

这时候你应该能正常登录Geoserver管理界面，所有403限制都会解除。

后续优化建议 #

1. 批量创建用户时添加延迟：循环创建账号时，每个请求之间添加1-2秒的延迟，避免短时间内触发防护阈值。
2. 调整防护阈值：登录Geoserver后，进入Security > Settings，找到Brute Force Protection配置项，调高"Maximum number of failures"（比如调到500）或者延长"Lockout duration"，适配你的批量操作需求。
3. 批量操作前临时关闭防护：如果需要频繁批量创建用户，可以在操作前修改bruteforce.properties关闭防护，操作完成后再重新开启。

内容的提问来源于stack exchange，提问作者cf2