Bots causing LDAP Lockouts

Hello,

Over the past week or so we’re seeing bots from all over attempting to make authenticated connections e.g.

185.220.102.8 - LDAPUser [02/May/2020:13:45:49 -0400] “GET /7e5d5f27d6374bbdb8ccca4b63255122/eb613e0a79a54e2ca9b0d6f7be2a553b.git/info/refs?service=git-upload-pack HTTP/1.1” 401 26 “” “git/2.24.1”

This is causing major headaches as the failed logins lock users accounts.

We have a robots.txt in place that instructs bots not to index the site at all but these bots are poorly behaved and appear to be ignoring it. We’ve verified that robots.txt is correct by using Google’s site tools and confirmed that Google at least no longer attempting to index. We also
tried GitLab’s rate limiting features but this doesn’t seem to do it.

Has anyone seen similar activity lately? Outside of disabling LDAP account integration, what else might we do to mitigate the issue? We are running GitLab Omnibus CE 12.10.2-ce.0

Thanks

John

Hi,

one mitigation would be to move the instance into your network and only allow access from trusted IP ranges (e.g. local company network and VPN).

From a security analysis perspective, I would look into patterns - does the username change, as in, to the bots traverse a list of all your LDAP usernames, or are these just a few.

185.220.102.8 seems to be a Tor exit note according to whois.

inetnum:        185.220.102.0 - 185.220.102.31
descr:          Zwiebelfreunde e.V.
netname:        ZWIEBELFREUNDE
remarks:        ---------------------------------
remarks:        This network is used for research
remarks:        in anonymization services and
remarks:        provides Tor exit nodes to end
remarks:        users.
remarks:        ---------------------------------
remarks:        Dieser Netzblock wird zur
remarks:        Erforschung von Anonymisierungs-
remarks:        techniken genutzt und stellt
remarks:        Endnutzern Tor zur Verfuegung.
remarks:        ---------------------------------
remarks:        http://www.torservers.net/abuse.html
remarks:        ---------------------------------

If it helps, block the IP address range 185.220.102.0/27 in your firewall and see whether the requests continue.

Cheers,
Michael

1 Like

Hi,

Thank you for the suggestions. I’ve looked into the origin of the IPs.
Yes, we’ve blocked all external access at this point, Not detectable pattern in the IPs. I see a variety, cloud providers, US based costs, non-US. I was hoping GitLab had some finer grained access control e.g. block access if the request URL matches a pattern of server=gitl-upload-pack.

John

Hi,

if the URL pattern really is what you find unique about this (you may accidentally break functionality) I could think of Nginx + fail2ban. While googling for it, I’ve found this document:

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

Might be worthwhile to investigate deeper. If it doesn’t work, you can still put an Nginx proxy up front, analyse the logs and let fail2ban and other tools do their automated blocking jobs.

Cheers,
Michael

1 Like