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?
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
email@example.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?
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.
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.
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.