Oct 29, 2020 - Charl de Wit and Greg Myers    

How we work to detect and mitigate Spam on GitLab.com and beyond

Working to fight spam and abuse can be a full time job. Here's how we do that for gitlab.com and some tips for self-hosted users.

This blog post is Unfiltered

We know spam can be a big problem. Beyond being annoying, abusive behavior, we know it affects workflows and performance and puts a strain on rate limits and brand reputation. We’re here to help. Our security team works around the clock to actively detect and mitigate spam for GitLab.com users and our product utilizes filters, captcha and user-defined configuration to help self-hosted instances prevent and mitigate spam and abuse. But, there’s always more that can be done. Below, we detail the work we do to protect .com users, offer up tips and best practices for self-hosted users, and talk about some new automation and tooling we’re exploring that will help all users prevent spam.

How we work to detect and mitigate spam on GitLab.com

Our Trust and Safety team works to investigate and protect against the malicious use of GitLab.com and it’s associated features and tools with the goal of making our product safer for our customers and the wider community. One of their focus areas surrounds the detection and mitigation of abusive activity on GitLab.com.

What is abuse?

We define abuse as the intentional misuse of GitLab products/services to cause harm or for personal gain which includes the distribution of malware, spam, and prohibited content. This activity is covered under Section 3 of the GitLab website Terms of Use. You can learn more about how we classify abuse in our handbook.

How to report abuse as a GitLab.com user

Users on GitLab.com can report abuse via the Report Abuse button while logged in. Alternately, users can email abuse reports to abuse@gitlab.com. Be sure to include any relevant information details in the issue or email so we can quickly and accurately understand the problem.

Self-managed customers: preventing, detecting and mitigating spam

GitLab uses Akismet Spam filter to check for spam when users create issues and reCaptcha as an added level of spam and abuse prevention.

This tooling helps respond to the symptoms of abuse, but the root of the problem remains: malicious actors register new accounts, or take over existing accounts and then use the accounts to spam and abuse instances and projects.

So, what more can you self-hosted Admins do to prevent and mitigate spam?

2FA

Hosted instances of GitLab can reduce spam by making it more difficult for bots to automate account creation or takeover. Requiring 2FA for all users is one way to prevent legitimate users from having their accounts taken over and used to create spam.

Authentication restrictions

Sign-up restrictions

Sign-up restrictions will allow self-hosted Admins to:

  • Disable new sign-ups.
  • Require Admin approval for new sign-ups.
  • Require user email confirmation.
  • Denylist or allowlist email addresses belonging to specific domains.

In fact, for customers running public-facing GitLab instances, we highly recommend that you consider disabling new sign-ups if you do not expect or want public users to sign up for an account on your instance.

Sign in restrictions

Sign in restrictions allow self-hosted Admins to customize authentication restrictions for web interfaces as well as Git over HTTP(S). These settings will allow you to enforce:

  • Mandatory 2FA for new users; this makes it more difficult for bots to surpass and prevents legitimate users from getting pwned via single factor authentication + weak password combinations.
  • Email confirmation on sign-up; making it more difficult for bots to register new spam accounts.

We know that spammers are humans (or humans running bots) and these configurations create additional work for illegitimate users with the intent to spam your instance; thus presenting a deterrent and making your instance a more difficult target.

Harden your instance

Also, customizing your instance configuration can go a long way to discourage and reduce spam and abuse. This includes defining how users access your instance and who can have access.

Understand how abuse is reported and managed by self-hosted Admins

It’s also key to understand how users can report abuse from other GitLab users to GitLab self-hosted Administrators, the actions that self-hosted Admins can take against abusers and how abuse reports are managed and resolved by Admins.

Rate limits

Finally, if you’re in the midst of spam abuse you can impose rate limits to help respond to the increased loads. You can also limit rates on issue creation and impose rate limits on user and IPs.

What’s next in spam and abuse prevention and detection

We continue to look for new ways to prevent, detect and mitigate abuse on GitLab.com and within our product. We are exploring alternate options for captcha to improve user experience and options to prevent bots posting URLs followed by crawlers to prevent spam. In addition, our security team is in the process of developing new automation to detect and prevent the creation of spam and are aiming to begin testing a first iteration on GitLab.com within the next 3 months. If successful, this is something we’ll look to incorporate into the product so all customers can benefit.

Suggestions and feature requests

If you have any suggestions or requests to improve abuse prevention on GitLab CE and EE, feel free to create a feature proposal issue from the provided templates in the GitLab Project and add the ~"Abuse Prevention" label. You can tag the Trust and Safety team on the issue for additional input @gitlab-com/gl-security/security-operations/trust-and-safety or if you have any questions.

Photo by Ranurte from Unsplash.

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg