nginx - puerto - GitLab emite prohibiciones temporales de IP-403 prohibido

gitlab url port

Question

La configuración de mi instancia de GitLab ocasionalmente establecerá una prohibición de IP en nuestra propia dirección IP, lo que resultará en que todos nuestros usuarios en la oficina obtengan 403 / Prohibido en cualquier página web o solicitud de git.

La prohibición se está implementando como resultado de la autenticación repetida de errores, lo cual es un problema aparte, pero me gustaría evitar que nuestra propia dirección IP sea prohibida por IP. Dura alrededor de una hora.

En los registros de nginx, nada inusual aparece en los archivos gitlab_access.log o gitlab_error.log. El servidor todavía se está ejecutando, y las direcciones IP externas no se ven afectadas mientras la prohibición está vigente.

Me gustaría poder incluir en la lista blanca nuestra propia dirección IP, o poder deshabilitar la prohibición una vez que ocurra (reiniciar gitlab no elimina la prohibición). Si ninguno de estos es posible, entonces solo sería correcto encontrar la configuración para modificar la duración de la prohibición desde una hora.

Answer 1

Siga los siguientes pasos para eliminar ban para su IP

1. Busque las direcciones IP que se han bloqueado en el registro de producción:

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

2. Dado que la lista negra está almacenada en Redis, necesita abrir redis-cli:

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

3. Puede eliminar el bloque usando la siguiente sintaxis, reemplazando con la IP real que está en la lista negra:

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

Fuente en GitLab Docs: eliminar las IP bloqueadas de Rack Attack a través de Redis

Answer 2

Estamos ejecutando Gitlab EE y para nosotros este problema se debió a una combinación de usar git lfs dentro de una compilación en un corredor de Gitlab CI, y haber instalado la gema de rack-attack en el servidor de Gitlab.

Fondo

Para solucionar un problema con git-lfs 1.2.1 (donde insistió en requerir un nombre de usuario y contraseña a pesar de la clonación de un repositorio público), la compilación contenía esta línea:

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

En la compilación, esto dio como resultado que cada solicitud de LFS desde el corredor activara un intento de inicio de sesión con fakeuser, lo que obviamente fallaba cada vez. Sin embargo, dado que el servidor no requirió realmente un inicio de sesión, el cliente podría continuar descargando los archivos utilizando LFS, y la compilación pasó.

Problema

La prohibición de IP comenzó cuando se instaló el paquete rack-attack . De forma predeterminada, después de 10 intentos de inicio de sesión fallidos, rack-attack prohibe la IP de origen durante una hora. Esto provocó que todos los corredores estuvieran completamente bloqueados de Gitlab (incluso visitar la página web del corredor devolvería 403 Forbidden ).

Solución (inseguro)

Una solución temporal a corto plazo, si los servidores (los corredores de Gitlab en nuestro caso) son confiables, es agregar las direcciones IP de los servidores a una lista blanca en la configuración de rack-attack en rack-attack . También es posible ajustar el tiempo de prohibición o permitir más intentos fallidos.

Ejemplo de configuración en /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
}

En este ejemplo, estamos en la lista blanca de los servidores 192.168.123.123 y 192.168.123.124 , y estamos reduciendo el tiempo de prohibición de una hora a 10 minutos (600 segundos). maxretry = 10 permite que un usuario obtenga la contraseña incorrecta 10 veces antes de la prohibición, y findtime = 60 significa que el contador de intentos fallidos se restablece después de 60 segundos.

Luego, debe reconfigurar gitlab antes de que los cambios surtan efecto: sudo gitlab-ctl reconfigure

Más detalles, y para la versión YAML del ejemplo de configuración, vea gitlab.yml.example .

NOTA: los servidores de la lista blanca son inseguros, ya que deshabilita completamente el bloqueo / limitación en las direcciones IP de la lista blanca.

Solución

La solución a este problema debería ser detener los intentos fallidos de inicio de sesión, o posiblemente reducir el tiempo de prohibición, ya que la lista blanca deja a Gitlab vulnerable a los ataques de fuerza bruta de contraseña de todos los servidores de la lista blanca.