GitLab 发布临时 IP 禁令 - 403 被禁止 [英] GitLab issuing temporary IP bans - 403 forbidden
问题描述
我的 GitLab 实例设置偶尔会对我们自己的 IP 地址设置 IP 禁令，导致我们办公室中的所有用户在任何网页或 git 请求上都收到 403/Forbidden.
My GitLab instance setup will occasionally put in place an IP ban on our own IP address, resulting in all our users in the office getting 403 / Forbidden on any web page or git request.
由于重复验证错误而实施了禁令，这完全是一个单独的问题，但我想防止我们自己的 IP 地址被 IP 禁止.持续约一小时.
The ban is being put in place as a result of repeated errors authenticating, which is a separate problem altogether, but I would like to prevent our own IP address from being IP banned. It lasts for about one hour.
在 nginx 日志中，gitlab_access.log 或 gitlab_error.log 文件中没有任何异常弹出.服务器仍在运行，并且在禁令生效期间外部 IP 地址不受影响.
In the nginx logs, nothing unusual pops up in the gitlab_access.log or gitlab_error.log files. The server is still running, and external IP addresses are unaffected while the ban is in place.
我希望能够将我们自己的 IP 地址列入白名单，或者能够在禁令发生后禁用(重新启动 gitlab 不会取消禁令).如果这些都不可能，那么只需找到将禁令持续时间从一小时调整为低的设置也可以.
I would like to be able to whitelist our own IP address, or to be able to disable the ban once it occurs (restarting gitlab doesn't remove the ban). If neither of these are possible, then just finding the setting to tweak the ban duration down from one hour would be OK too.
推荐答案
我们正在运行 Gitlab EE，对我们来说这个问题是由于使用 git lfs 在 Gitlab CI 运行器的构建中，以及 已安装 rack-attackgem 在 Gitlab 服务器上.
We are running Gitlab EE and for us this issue was caused by a combination of using git lfs inside a build on a Gitlab CI runner, and having installed the rack-attack gem on the Gitlab server.
为了解决 git-lfs 1.2.1 的问题(尽管克隆了公共存储库，它仍坚持要求用户名和密码)，构建包含以下行:
In order to work around an issue with git-lfs 1.2.1 (where it insisted on requiring username and password despite cloning a public repository), the build contained this line:
git clone https://fakeuser:fakepassword@git.domain.com/group/repo.git
在构建时，这导致来自运行器的每个 LFS 请求都会触发使用 fakeuser 的登录尝试，显然每次都失败.但是，由于服务器实际上不需要登录，因此客户端可以继续使用 LFS 下载文件，并且构建通过.
On build, this resulted in every LFS request from the runner triggering a login attempt with fakeuser, which obviously failed every time. However, since no login was actually required by the server, the client could continue downloading the files using LFS, and the build passed.
安装包 rack-attack 时 IP 禁止开始.默认情况下，在 10 次登录尝试失败后，rack-attack 会禁止源 IP 1 小时.这导致所有跑步者都被 Gitlab 完全阻止(即使从跑步者访问网页也会返回 403 Forbidden).
The IP banning started when the package rack-attack was installed. By default, after 10 failed login attempts, rack-attack bans the origin IP for one hour. This resulted in all runners being completely blocked from Gitlab (even visiting the web page from the runner would return 403 Forbidden).
如果服务器(在我们的例子中是 Gitlab 运行器)是受信任的，则短期解决方法是将服务器的 IP 添加到 rack-attack 配置中的白名单中.调整封禁时间，或允许更多失败的尝试，也是可能的.
A short-term workaround, if the servers (Gitlab runners in our case) are trusted, is to add the servers' IPs to a whitelist in the rack-attack configuration. Adjusting the ban time, or allowing more failed attempts, is also possible.
/etc/gitlab/gitlab.rb中的示例配置:
gitlab_rails['rack_attack_git_basic_auth'] = {
'enabled' => true,
'ip_whitelist' => ["192.168.123.123", "192.168.123.124"],
'maxretry' => 10,
'findtime' => 60,
'bantime' => 600
}
在本例中，我们将服务器 192.168.123.123 和 192.168.123.124 列入白名单，并将禁用时间从 1 小时调整为 10 分钟(600 秒).maxretry = 10 允许用户在禁止前密码错误 10 次，findtime = 60 表示失败尝试计数器在 60 秒后重置.
In this example, we are whitelisting the servers 192.168.123.123 and 192.168.123.124, and adjusting down the ban time from one hour to 10 minutes (600 seconds). maxretry = 10 allows a user to get the password wrong 10 times before ban, and findtime = 60 means that the failed attempts counter resets after 60 seconds.
然后，您应该在更改生效之前重新配置 gitlab:sudo gitlab-ctl reconfigure
Then, you should reconfigure gitlab before changes take effect: sudo gitlab-ctl reconfigure
更多详细信息，有关配置示例的 YAML 版本，请参阅 gitlab.yml.example.
More details, and for the YAML version of the config example, see gitlab.yml.example.
注意:将服务器列入白名单是不安全的，因为它会完全禁用对列入白名单的 IP 的阻止/限制.
NOTE: whitelisting servers is insecure, as it fully disables blocking/throttling on the whitelisted IPs.
这个问题的解决方案应该是停止失败的登录尝试，或者可能只是减少禁止时间，因为白名单会使 Gitlab 容易受到来自所有白名单服务器的密码暴力攻击.
The solution to this problem should be to stop the failing login attempts, or possibly just reduce the ban time, as whitelisting leaves Gitlab vulnerable to password brute-force attacks from all whitelisted servers.
这篇关于GitLab 发布临时 IP 禁令 - 403 被禁止的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
