gitlab的rack-attack机制和如何设置白名单的记录

目标gitlab是使用源码安装的10.5中文版

大纲:

gitlab rack-attack 机制的作用

如何启用和禁用gitlab的rack-attack机制,以及如何配置白名单

如果一个ip被错误地拦截,导致了不能访问,如何快速地恢复

如果gitlab工作在一个反向代理(或者是负载均衡器)的后边,会导致的问题和解决的方法

如何写出一个可以触发拦截机制的测试用例

正文:

1.gitlab rack-attack 机制的作用

gitlab的rack-attack机制是为了限制某个ip对gitlab进行基本认证失败请求的次数,杜绝恶意的攻击和密码破解等行为,通过限制每个ip每分钟内尝试的基本认证的次数来实现,如果某个ip进行的基本认证失败请求的次数超过这个限制,则这个ip的其他的所有的请求都会返回403

2.如何启用和禁用gitlab的rack-attack机制,以及如何配置白名单

我们使用的是从源码安装的gitlab,rack-attack机制默认是启用的,如果想要禁用掉这个机制,只需要修改 /home/git/gitlab/config/gitlab.yml

将下图中的enabled改为false,然后取消注释即可:

如果想要配置不拦截某个IP地址,则将上边的ip_whitelist配置取消注释,将不拦截的ip地址配置进去即可,如果有多个地址的话,中间用逗号进行分隔.

3.如果一个ip被错误地拦截,导致了不能访问,如何快速地恢复

如果一个地址被拦截,则gitlab会将这个拦截的地址写入redis里边,如果想要迅速地恢复这个地址的请求,则将这条拦截的记录从redis里边删除即可

具体的操作的方法如下:

查看日志,找到被拦截的IP地址是什么:

grep "Rack_Attack" /日志目录/production.log

进入redis :

redis-cli -s /var/run/redis/redis.sock

查看相关的cache key:

keys *rack::attack*

删除掉该key对应的值:

del cache:gitlab:rack::attack:allow2ban:ban:<前边找到的IP地址>

4.如果gitlab工作在一个反向代理或者是负载均衡后边,导致gitlab拿到的请求地址都是反向代理(或者负载均衡器)的IP地址,而不是用户真实的IP地址,会导致rack-attack起不到我们想要的作用,这时候该如何配置让gitlab读取到用户真实的ip地址来选择禁用,而不是禁用掉反向代理的地址呢?

参考gitlab的官方文档,配置trusted_proxy,并传递用户真实的IP地址

5.如何写出一个可以触发拦截机制的测试用例

rack_attack的规则是计算某个ip在某段时间里边的失败的基本认证的次数,默认是一分钟内大于10次则拦截这个ip,所以想要人为出发这个拦截机制,只需要用基本认证的方式和错误的用户名密码来不断请求gitlab相关地址就可以了,默认情况下,快速请求10次就可以触发403了

11.x版本开始,rack-attack功能默认都是禁用的了,如果需要这个功能,需要手动修改配置文件来开启

官方文档的位置:

https://docs.gitlab.com/ee/security/rack_attack.html