web-dev-qa-db-fra.com

GitLab émet des interdictions temporaires de propriété intellectuelle - 403 interdites

La configuration de mon instance GitLab mettra parfois en place une interdiction IP sur notre propre adresse IP. Tous nos utilisateurs du bureau recevront donc 403/Forbidden sur toute page Web ou demande git.

L'interdiction est mise en place à la suite d'erreurs répétées d'authentification, ce qui est un problème à part entière, mais je voudrais éviter que notre propre adresse IP soit bannie. Cela dure environ une heure.

Dans les journaux nginx, rien d’inhabituel n’apparaît dans les fichiers gitlab_access.log ou gitlab_error.log. Le serveur est toujours en cours d'exécution et les adresses IP externes ne sont pas affectées tant que l'interdiction est en place.

J'aimerais pouvoir ajouter notre propre adresse IP à la liste blanche ou pouvoir désactiver l'interdiction une fois qu'elle est déclenchée (le redémarrage de gitlab ne supprime pas l'interdiction). Si aucune de ces solutions n'est possible, il vous suffira également de définir le réglage pour ajuster la durée d'interdiction d'une heure à une heure.

nginxgitlab
19
Blazing

Nous utilisons Gitlab EE et ce problème a été causé pour nous par une combinaison de l'utilisation de git lfs dans une version d'un coureur Gitlab CI et de ayant installé le rack-attack gem sur le serveur Gitlab.

Contexte

Afin de contourner un problème avec git-lfs 1.2.1 (où il insistait pour exiger un nom d'utilisateur et un mot de passe malgré le clonage d'un référentiel public), la construction contenait la ligne suivante:

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

Lors de la construction, chaque demande LFS du coureur était déclenchée par une tentative de connexion avec fakeuser, qui échouait évidemment à chaque fois. Cependant, étant donné qu'aucune connexion n'était réellement requise par le serveur, le client pouvait continuer à télécharger les fichiers à l'aide de LFS et la construction était transmise.

Problème

L’interdiction IP a commencé lors de l’installation du paquet rack-attack. Par défaut, après 10 tentatives de connexion infructueuses, rack-attack interdit l'IP d'origine pendant une heure. Cela a eu pour résultat que tous les coureurs ont été complètement bloqués par Gitlab (même la visite de la page Web du coureur renverrait 403 Forbidden).

Contournement (non sécurisé)

Une solution à court terme, si les serveurs (les coureurs Gitlab dans notre cas) sont approuvés, consiste à ajouter les adresses IP des serveurs à une liste blanche dans la configuration rack-attack. Il est également possible de régler le temps d'interdiction ou d'autoriser plus de tentatives infructueuses.

Exemple de configuration dans /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
}

Dans cet exemple, nous mettons en liste blanche les serveurs 192.168.123.123 et 192.168.123.124 et réduisons le délai d'interdiction d'une heure à 10 minutes (600 secondes). maxretry = 10 permet à un utilisateur d'obtenir le mot de passe incorrect 10 fois avant l'interdiction, et findtime = 60 signifie que le compteur de tentatives infructueuses est réinitialisé après 60 secondes.

Ensuite, vous devriez reconfigurer gitlab avant que les modifications ne prennent effet: Sudo gitlab-ctl reconfigure

Plus de détails, et pour la version YAML de l'exemple de configuration, voir gitlab.yml.example .

REMARQUE: la liste blanche des serveurs n'est pas sécurisée, car elle désactive complètement le blocage/la limitation des adresses IP de la liste blanche.

Solution

La solution à ce problème devrait être d'arrêter les tentatives de connexion infructueuses, ou peut-être simplement de réduire le temps d'interdiction, car la liste blanche laisse Gitlab vulnérable aux attaques par force brutale par mot de passe de tous les serveurs figurant sur la liste blanche.

15
jonatan

Suivez les étapes suivantes pour supprimer l'interdiction pour votre adresse IP

  1. Recherchez les adresses IP bloquées dans le journal de production:

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

  2. Comme la liste noire est stockée dans Redis, vous devez ouvrir redis-cli:

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

  3. Vous pouvez supprimer le bloc en utilisant la syntaxe suivante, en le remplaçant par l'adresse IP réelle figurant sur la liste noire:

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

Source sur GitLab Docs: Supprimer les IP bloquées de Rack Attack via Redis

0
Pavlo Neyman