GitLab发布临时IP禁令-禁止403 [英] GitLab issuing temporary IP bans - 403 forbidden
问题描述
我的GitLab实例设置有时会在我们自己的IP地址上设置IP禁令，导致我们办公室中的所有用户在任何网页或git请求上都获得403/禁止访问.
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，对我们来说，此问题是由使用 rack-attack gem .
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一小时.这导致所有跑步者都被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列入白名单，并将禁止时间从一小时降低到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屋！
