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.
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.
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.
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
).
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.
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.
Suivez les étapes suivantes pour supprimer l'interdiction pour votre adresse IP
Recherchez les adresses IP bloquées dans le journal de production:
grep "Rack_Attack" /var/log/gitlab/gitlab-Rails/production.log
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
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