Rack::Attack IP blacklist bans the IP from all requests
This discussion started from gitlab-com/www-gitlab-com#5708 (comment 239152738). Copying the relevant parts here:
What happens now is that multiple failed Git HTTP auths would cause the IP to be blacklisted. When the IP is blacklisted, all requests to any endpoint from that IP are blocked. Is this intended? Or do we want to only blacklist Git auth?
If we only blacklist Git and skip the check for all other requests it could potentially save us a lot of these
GET
calls because we don't have to do this for every request anymore.
From @jacobvosmaer-gitlab:
I can say something about what I remember about that time. It may not be up to date though.
- When I joined GitLab there was no throttling on log-in attempts or anything.
- We added Rack::Attack to throttle
/users/sign_in
- It got pointed out that Git HTTP was exposed: at the time there were no access tokens so you had to use your full, normal password for Git HTTP and you could hammer the HTTP endpoints to guess passwords
- We built a complex hack that allowed the Git HTTP auth logic to re-use the Rack::Attack banning middleware
- We learned that Git HTTP clients always start by making a request without sending auth; then they get 401, and resubmit with auth. And for a while, we were counting these requests without auth as failures towards banning. Solution: more complex stuff.
- ... years pass
- I am not involved anymore in how this part of gitlab works, and I don't know what happened in the meantime
The one thing I can say is that bonafide Git HTTP clients still send lots of requests that lack credentials, and we should not ban those. Git HTTP credentials absent: normal. Git HTTP credentials present but wrong: bad, count towards banning.