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:

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:

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. For current, working product improvements to detect and mitigate spam, see our active merge requests.

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. For more information on how to contact our Trust & Safety Team, see our handbook.

Photo by Ranurte from Unsplash.

60天免费试用极狐GitLab专业版

极狐GitLab不仅是源代码管理或CI/CD工具,它是一个覆盖完整软件开发生命周期和DevOps的开放式一体化平台。

企业版试用
售前咨询
联系电话
在线支持
预约演示