GitLab发布临时知识产权禁令 – 403禁止

我的GitLab实例设置偶尔会对我们自己的IP地址实施IP禁令，导致我们在办公室的所有用户在任何网页或者git请求中获得403 / Forbidden。

禁令是由于重复的validation错误而产生的，这是一个单独的问题，但是我想阻止我们自己的IP地址被IP禁止。 它持续约一个小时。

在Nginx日志中，gitlab_access.log或gitlab_error.log文件中没有任何exception。 服务器仍在运行，并且在禁用期间外部IP地址不受影响。

我希望能够将我们自己的IP地址列入白名单，或者一旦发生禁用，就可以禁用此项禁令（重新启动gitlab不会取消禁止）。 如果这两者都不可能，那么只要find将禁令持续时间从一个小时缩短的设置就可以了。

是否有可能build立一个GitLab Linux服务器和Windows PC的工作？

Gitlab私人项目接受任何人的推动

Gitlab 5.3后面的Nginx反向代理

安装GitLab并让它在子域上运行

git ssh请求gitlab的密码

Gitlab：运行Unicorn的问题，Resque with Passenger / Nginx

为什么这个Nginx conf允许访问其他主机名/端口上的Gitlab？

使用现有的Nginx安装转发到GitLab子域

Nginx对Gitlab-workhorse套接字需要什么权限？

权限被拒绝（publickey） – Windows上的Git Bash

我们正在运行Gitlab EE，对于我们来说，这个问题是由在Gitlab CI运行器上使用git lfs内部组合引起的，并且已经在Gitlab服务器上安装了rack-attack gem 。

背景

为了解决git-lfs 1.2.1一个问题（尽管克隆一个公共仓库，它坚持要求用户名和密码），构建包含这一行：

git clone https://fakeuser:[e-mail]/group/repo.git

在构建时，这导致跑步者的每个LFS请求都会触发fakeuser登录尝试，而这种尝试显然每次都会失败。 但是，由于服务器实际上不需要登录，客户端可以继续使用LFS下载文件，并且构建通过。

问题

包装rack-attack安装时，IP禁止开始。 缺省情况下，10次登录失败后， rack-attack禁止一个小时的源IP。 这导致所有的跑步者完全被Gitlab拦截（即使访问跑步者的网页也会返回403 Forbidden ）。

解决方法（不安全）

一个短期的解决方法是，如果服务器（在我们的例子中是Gitlab跑步者）是受信任的，就是在rack-attack配置中将服务器的IP添加到白名单中。 调整禁令时间，或允许更多的失败尝试，也是可能的。

/etc/gitlab/gitlab.rb配置/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秒后重置。

更多细节，请参阅gitlab.yml.example 。

注意：白名单服务器是不安全的，因为它完全禁用白名单IP上的阻塞/限制。

解

这个问题的解决方案应该是停止失败的登录尝试，或者可能只是减少禁止时间，因为白名单使得Gitlab容易受到来自所有白名单服务器的密码暴力攻击的威胁。