GitLab 发布临时 IP 禁令 - 403 禁止
GitLab issuing temporary IP bans - 403 forbidden
我的 GitLab 实例设置有时会在我们自己的 IP 地址上设置 IP 禁令,导致我们办公室的所有用户在任何网页或 git 请求上都收到 403 / Forbidden。
由于身份验证反复出错,该禁令正在实施,这完全是一个单独的问题,但我想防止我们自己的 IP 地址被 IP 禁止。持续约一小时。
在 nginx 日志中,gitlab_access.log 或 gitlab_error.log 文件中没有弹出任何异常。服务器仍然 运行,在禁令实施期间外部 IP 地址不受影响。
我希望能够将我们自己的 IP 地址列入白名单,或者能够在禁令发生后将其禁用(重新启动 gitlab 不会解除禁令)。如果这些都不可能,那么只要找到将禁令持续时间从一小时缩短的设置也可以。
我们是 运行 Gitlab EE,对我们来说,这个问题是由在 Gitlab 服务器上使用 git lfs
inside a build on a Gitlab CI runner, and having installed the rack-attack
gem 的组合引起的。
背景
为了解决 git-lfs 1.2.1
的问题(尽管克隆了 public 存储库,它仍坚持要求用户名和密码),构建包含以下行:
git clone https://fakeuser:fakepassword@git.domain.com/group/repo.git
在构建时,这导致来自运行器的每个 LFS 请求都触发使用 fakeuser 的登录尝试,显然每次都失败了。然而,由于服务器实际上不需要登录,客户端可以继续使用 LFS 下载文件,并且构建通过。
问题
安装包 rack-attack
时 IP 封禁开始。默认情况下,在 10 次登录尝试失败后,rack-attack
禁止源 IP 一小时。这导致所有跑步者被 Gitlab 完全阻止(即使从跑步者访问网页也会 return 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 上的 blocking/throttling。
解决方案
这个问题的解决方案应该是停止失败的登录尝试,或者可能只是减少禁令时间,因为白名单使 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 文档上的来源:Remove blocked IPs from Rack Attack via Redis
gitlab使用redis存储banned ip,找到redis key,
- 用
sudo find / -name redis.conf
找到 redis 配置文件 redis.conf
/var/opt/gitlab/redis/redis.conf
- 找到
sudo grep unixsocket /var/opt/gitlab/redis/redis.conf
的 redis 套接字
unixsocket /var/opt/gitlab/redis/redis.socket
- 通过
redis-cli -s /var/opt/gitlab/redis/redis.socket
通过套接字连接到redis服务器,然后找到并删除被禁止的ip
redis-cli -s /var/opt/gitlab/redis/redis.socket
redis /var/opt/gitlab/redis/redis.socket> keys *attack*
"cache:gitlab:rack::attack:allow2ban:ban:115.171.85.150"
redis /var/opt/gitlab/redis/redis.socket> del cache:gitlab:rack::attack:allow2ban:ban:115.171.85.150
我的 GitLab 实例设置有时会在我们自己的 IP 地址上设置 IP 禁令,导致我们办公室的所有用户在任何网页或 git 请求上都收到 403 / Forbidden。
由于身份验证反复出错,该禁令正在实施,这完全是一个单独的问题,但我想防止我们自己的 IP 地址被 IP 禁止。持续约一小时。
在 nginx 日志中,gitlab_access.log 或 gitlab_error.log 文件中没有弹出任何异常。服务器仍然 运行,在禁令实施期间外部 IP 地址不受影响。
我希望能够将我们自己的 IP 地址列入白名单,或者能够在禁令发生后将其禁用(重新启动 gitlab 不会解除禁令)。如果这些都不可能,那么只要找到将禁令持续时间从一小时缩短的设置也可以。
我们是 运行 Gitlab EE,对我们来说,这个问题是由在 Gitlab 服务器上使用 git lfs
inside a build on a Gitlab CI runner, and having installed the rack-attack
gem 的组合引起的。
背景
为了解决 git-lfs 1.2.1
的问题(尽管克隆了 public 存储库,它仍坚持要求用户名和密码),构建包含以下行:
git clone https://fakeuser:fakepassword@git.domain.com/group/repo.git
在构建时,这导致来自运行器的每个 LFS 请求都触发使用 fakeuser 的登录尝试,显然每次都失败了。然而,由于服务器实际上不需要登录,客户端可以继续使用 LFS 下载文件,并且构建通过。
问题
安装包 rack-attack
时 IP 封禁开始。默认情况下,在 10 次登录尝试失败后,rack-attack
禁止源 IP 一小时。这导致所有跑步者被 Gitlab 完全阻止(即使从跑步者访问网页也会 return 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 上的 blocking/throttling。
解决方案
这个问题的解决方案应该是停止失败的登录尝试,或者可能只是减少禁令时间,因为白名单使 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 文档上的来源:Remove blocked IPs from Rack Attack via Redis
gitlab使用redis存储banned ip,找到redis key,
- 用
sudo find / -name redis.conf
找到 redis 配置文件
redis.conf
/var/opt/gitlab/redis/redis.conf
- 找到
sudo grep unixsocket /var/opt/gitlab/redis/redis.conf
的 redis 套接字
unixsocket /var/opt/gitlab/redis/redis.socket
- 通过
redis-cli -s /var/opt/gitlab/redis/redis.socket
通过套接字连接到redis服务器,然后找到并删除被禁止的ip
redis-cli -s /var/opt/gitlab/redis/redis.socket
redis /var/opt/gitlab/redis/redis.socket> keys *attack*
"cache:gitlab:rack::attack:allow2ban:ban:115.171.85.150"
redis /var/opt/gitlab/redis/redis.socket> del cache:gitlab:rack::attack:allow2ban:ban:115.171.85.150