GitLab выпускает временные запреты IP-адресов - 403 запрещено

Ответ 1

Мы работаем с Gitlab EE, и для нас эта проблема была вызвана комбинацией использования git lfs внутри сборки на Gitlab CI runner и установкой rack-attack gem на сервере Gitlab.

Фон

Чтобы обойти проблему с git-lfs 1.2.1 (где он настаивал на том, чтобы требовать имя пользователя и пароль, несмотря на клонирование открытого репозитория), сборка содержала следующую строку:

git clone https://fakeuser:[email protected]/group/repo.git

При сборке это приводило к тому, что каждый LFS-запрос от бегуна вызывал попытку входа в систему с помощью fakeuser, которая каждый раз явно не выполнялась. Однако, поскольку сервер фактически не требовал входа в систему, клиент мог продолжить загрузку файлов с использованием LFS, и сборка прошла.

Выпуск

Запрет IP начался, когда был установлен пакет rack-attack. По умолчанию после 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 уязвимым для атак с использованием паролей со всех сторон.

Ответ 2

Выполните следующие шаги, чтобы удалить бан для вашего IP

1. Найдите заблокированные IP-адреса в производственном журнале:

   grep "Rack_Attack" /var/log/gitlab/gitlab-rails/production.log

2. Поскольку черный список хранится в Redis, вам нужно открыть redis-cli:

   /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket

3. Вы можете удалить блок, используя следующий синтаксис, заменив его фактическим IP, занесенным в черный список:

   del cache:gitlab:rack::attack:allow2ban:ban:<ip>

Источник на GitLab Docs: Удалить заблокированные IP-адреса из Rack Attack через Redis

Ответ 3

gitlab использует redis для хранения заблокированного ip, чтобы найти ключ redis,

1. найти файл конфигурации redis redis.conf с помощью sudo find / -name redis.conf

/var/opt/gitlab/redis/redis.conf

2. найти сокет redis с помощью sudo grep unixsocket /var/opt/gitlab/redis/redis.conf

unixsocket /var/opt/gitlab/redis/redis.socket

3. подключитесь к redis серверу с сокетом по redis-cli -s /var/opt/gitlab/redis/redis.socket, затем найдите и удалите заблокированный 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