Bla*_*ing 22 nginx ip-address access-control gitlab
我的GitLab实例设置偶尔会对我们自己的IP地址实施IP禁止,导致我们办公室的所有用户在任何网页或git请求上获得403/Forbidden.
由于重复的错误验证,禁令正在实施,这完全是一个单独的问题,但我想阻止我们自己的IP地址被IP禁止.它持续约一个小时.
在nginx日志中,gitlab_access.log或gitlab_error.log文件中没有任何异常弹出.服务器仍在运行,禁止到位时外部IP地址不受影响.
我希望能够将我们自己的IP地址列入白名单,或者能够在禁令发生后禁用该禁令(重启gitlab不会取消禁令).如果这些都不可能,那么只需找到将禁令持续时间调整为一小时的设置也可以.
jon*_*tan 16
我们正在运行Gitlab EE对于我们这个问题是通过使用共同造成git lfs上Gitlab CI亚军构建里面,已经安装了rack-attack宝石的Gitlab服务器上.
为了解决一个问题git-lfs 1.2.1(尽管克隆公共存储库它仍坚持要求用户名和密码),构建包含以下行:
git clone https://fakeuser:fakepassword@git.domain.com/group/repo.git
在构建时,这导致来自跑步者的每个LFS请求触发使用fakeuser的登录尝试,这显然每次都失败.但是,由于服务器实际上不需要登录,因此客户端可以继续使用LFS下载文件,并传递构建.
rack-attack安装软件包后就开始了IP禁止.默认情况下,在10次登录尝试失败后,rack-attack禁止原始IP一小时.这导致所有跑步者完全被Gitlab阻止(即使从跑步者那里访问网页也会返回403 Forbidden).
短期解决方法,如果服务器(在我们的例子中是Gitlab运行程序)是可信的,则将服务器的IP添加到rack-attack配置中的白名单.调整禁止时间或允许更多失败的尝试也是可能的.
配置示例/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:sudo gitlab-ctl reconfigure
更多详细信息,以及YAML配置示例的版本,请参阅gitlab.yml.example.
注意:白名单服务器不安全,因为它完全禁用白名单IP上的阻止/限制.
此问题的解决方案应该是停止失败的登录尝试,或者可能只是减少禁止时间,因为白名单会使Gitlab容易受到所有列入白名单的服务器的密码暴力攻击.
请按照以下步骤删除对IP的禁止
在生产日志中找到已被阻止的IP：
grep "Rack_Attack" /var/log/gitlab/gitlab-rails/production.log
由于黑名单存储在Redis中，因此需要打开redis-cli：
/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
您可以使用以下语法删除该阻止，而将其替换为列入黑名单的实际IP：
del cache:gitlab:rack::attack:allow2ban:ban:<ip>
GitLab文件上的来源：通过Redis从机架攻击中删除被阻止的IP