I can take down our private gitlab instance with one command

379 views
Skip to first unread message

Dan Kegel

unread,
Jul 22, 2016, 6:12:48 PM7/22/16
to GitLab
All I have to do is turn on build support, grab the ci token from the
settings page, do
git clone g...@gitlab.removed.com:pastries/funkychicken.git
git remote add httpsorigin
https://gitlab-ci-token:REM...@gitlab.removed.com/pastries/funkychicken.git
git lfs pull httpsorigin
and bammo, our gitlab server blacklists our site's IP address.
Turns out that one 'git lfs pull' command generates ten https fetches
in quick succession, and the DOS attack defense module
flags this legitimate use as an attack.

Our IT called the support guys, and they claimed this was
not a bug, but they didn't understand that the problem was
caused by a single git lfs pull.

Stan Hu

unread,
Jul 22, 2016, 6:38:50 PM7/22/16
to gitl...@googlegroups.com

Thanks for reporting. You may want to try disabling Rack Attack until we resolve the issue. To /etc/gitlab/gitlab.rb, add:

gitlab_rails['rack_attack_git_basic_auth'] = {
   'enabled' => false
}
Then run `sudo gitlab-ctl reconfigure`.


--
You received this message because you are subscribed to the Google Groups "GitLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gitlabhq+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/CAPF-yOY8VrfZXH3kWOXmuELwxzxYaDWAB%3Dn48xB9ZM%3DjkiOFHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Dan Kegel

unread,
Jul 22, 2016, 6:41:34 PM7/22/16
to GitLab, cgo...@oblong.com
On Fri, Jul 22, 2016 at 3:38 PM, Stan Hu <sta...@gmail.com> wrote:
> Thanks for reporting. You may want to try disabling Rack Attack until we
> resolve the issue.

Thanks. Tried that. Now the symptom is different:

$ git lfs install
$ git lfs clone
https://gitlab-ci-token:REM...@gitlab.removed.com/pastries/funkychicken.git
Cloning into 'funkychicken'...
remote: Counting objects: 67, done.
remote: Compressing objects: 100% (65/65), done.
remote: Total 67 (delta 19), reused 7 (delta 0)
Unpacking objects: 100% (67/67), done.
Checking connectivity... done.
warning: current Git remote contains credentials
warning: current Git remote contains credentials
warning: current Git remote contains credentials
warning: current Git remote contains credentials
warning: current Git remote contains credentials
warning: current Git remote contains credentials
warning: current Git remote contains credentials
warning: current Git remote contains credentials
...
and it never finishes. Looks like it's doing the same https fetches
over and over, about once a second.

Dan Kegel

unread,
Jul 22, 2016, 7:32:13 PM7/22/16
to GitLab, cgo...@oblong.com
Tried it with plain old https authentication via prompting or cache,
worked fine.

Tried it with plain old https authentication via jamming username and
password into git url, got the infinite loop again.

That narrows it down a bit - has nothing to do with ci tokens, and
more to do with how urls containing explicit authentication are
handled.
(And it's not surprising there might be a problem there, that feature
is seldom used. It'll be used more now that ci tokens are supported,
I bet.)
Reply all
Reply to author
Forward
0 new messages