7 ms·
Gitlab Project Hit by Spambot
- arusahni 6y agoHere's their incident status: https://status.io/pages/incident/5b36dc6502d06804c08349f7/60213010d6d39f2aa481229b https://status.io/pages/incident/5b36dc6502d06804c08349f7/60... Looks like the immediate issue was resolved a few minutes ago.
- boleary-gl 6y agoGitLab team member here. We're actively working on mitigating this spam attack: https://twitter.com/gitlabstatus/status/1358777539624198145 https://twitter.com/gitlabstatus/status/1358777539624198145
- jeanlucas 6y agoIs it spam or a "mail ddos"?
- boleary-gl 6y agoBoth?
- jdsalaro 6y agoStrictly speaking the former. You could, however, say it's both since submitted issues trigger an e-mail being sent to people following the project.
- saurabhnanda 6y agoWhat is this going to do to their Sendgrid/SES bill this month, I wonder!
- jitbit 6y agoWe are a small SaaS vendor and fighting spam is, like, 20% of the technical work that we do. Bad actors register trial accounts and then reverse engineer your front-end and forge millions of requests. Just 2 days ago we had a very similar issue [1] We have all sorts of protection: rate limiting, crippling non-paid accounts, detecting if a trial signup comes from a VPN/Tor (+5 to "suspicious" score!) etc... But they still manage to find ways. It's a never-ending battle. And the saddest part is - all this hard work is completely invisible to our existing paying customers :( If your app has an email-sending module of some sort it WILL be abused. Even a trivial "reset password" form is a target. My support goes to the GitLab team. Good luck and no hard feelings. [1] https://www.jitbit.com/news/5354-spammer-attack-post-mortem/ https://www.jitbit.com/news/5354-spammer-attack-post-mortem/
- gogopuppygogo 6y agoSounds like something a lot of companies need. Could be a good lifestyle startup company.
- nathancahill 6y agoRequire a credit card on signup.
- wu_187 6y agoThat won't work as the same bad actors typically dabble in CC fraud as well. They will typically already have thousands of CC numbers at their disposal.
- dec0dedab0de 6y agoCredit card and a delay.
- applecrazy 6y agoThat would basically destroy user acquisition metrics. As a user, I don’t want to wait days to get access to something.
- sushikokk 6y agoMaybe they flood the mailbox to hide legit mails in between all the spam mails, like password changes or other important notifications?
- CatTheHacker 6y agoHappens on GitHub as well, fortunately not with such massive flood
- bennyp101 6y agoInteresting that both Gitlab and Github had issues today - coincidence? Maybe Bitbucket will be next!
- xeeeeeeeeeeenu 6y agoIt's interesting that the nickname of the spammer is "fixspam gitlab". It seems that their intention is to force gitlab to introduce anti-spam measures.
- viraptor 6y agoCould be... I've seen this before - people annoyed by continuous low effort spam and the service not fixing it, deciding to show what a targeted attack will look like to force a response. (Not saying that GL doesn't care)
- markmacardle 6y agowhat is the motivation behind attacks like this? Like is whoever put in the effort to do this just trying to annoy Gitlab's customers? What do they gain from that?
- talhah 6y agoJudging from the example email the name of the spammer is "fixspam gitlab", I'm guessing they want gitlab to fix spam.
- jancsika 6y agoI run my own instance of Gitlab which basically means that I handle spam manually. It is a pain. Gitlab recently added a band-aid of a feature to require admin approval for new sign-ups, which comes with its own obvious problems. But even the UI for that is clunky-- you have to click a button to reveal some options, find the option to delete the spammer, type (read: paste) the users handle as a failsafe, after which Gitlab takes you back to the main user view requiring you to click again on the unverified users tab. Last time I talked about this problem someone from Gitlab claimed they were working on a feature to send an email with a simple link to click to approve/deny a user. That feature still has not shipped. They did fix an unrelated catastrophic bug of keeping around artifacts on each branch even if you set an expiry. On a gitlab instance with even moderate development rate and moderate-sized artifacts this fills up the hard-disk with artifacts that the admin must manually delete (or manually create their own script to delete them, which is still a pain). However, their fix was to add a checkbox that defaults to the buggy behavior. Per project. So for every new user's project I have to manually tell them to turn this anti-feature off to keep from filling up the hard-drive with artifact spam. Or else write a damned script to go in and turn off this feature periodically. The community edition of Gitlab feels a lot like the early Gnome 3 touch-screen stuff. Great in theory, but one quickly gets the sense that no one is dogfooding-- if they did these kinds of problems wouldn't exist.
- xrd 6y agoWhy isn't there an email provider that allows you to 1) whitelist the content and 2) manually register the to and from addresses and 3) specify how many emails you estimate you will be sending? At first glance, #1 seems tricky. But, I could see this as an opportunity to bring my users back to the site by providing very specific content teasers. #2 feels possible in certain circumstances. If you can register the addresses when the user registers, you could avoid problems like changing addresses. #3 seems like it would be problematic for the email provider who probably doesn't want to build a feature that reduces the ability to bill you. But I would pay for it. If you had all this, couldn't this prevent the problems described here and incentivize the spammers to find a different, easier target?