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

标签：hit   而不是   ack   bubuko   att   一个   破解   密码   返回   

目标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 Attach" /日志目录/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地址来选择禁用,而不是禁用掉反向代理的地址呢?

补充.....

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

补充......

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

官方文档的位置:
https://docs.gitlab.com/ee/security/rack_attack.html

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

标签：hit   而不是   ack   bubuko   att   一个   破解   密码   返回   

原文地址：https://www.cnblogs.com/jiaoyiping/p/9351099.html