graystevens

It certainly depends how your company views its risks and how docker fits into their “threat model” - you’re running someone else’s code on your secure internal networks, so it should be treated like external/unauthorised software.

It’s not unheard of for Docker images to be backdoored or tampered with, just look at last month - https://arstechnica.com/information-technology/2018/06/backd...

If they’re trivial images, maybe mirror them internally and walk through their internals if that doesn’t consume too much time.

I'll add another data point, from the consumer telecoms industry. 90% feels way too high from what we had to head with, even prior to implementing rate-limiting and other defences.

We ended up tracking actors as they switched up their techniques to evade us and our defences, and ended up learning a lot about credential stuffing, the tools involved and some of the motives behind them attacking lesser-known websites. We ended up blogging about our findings, should anyone else have to deal with this cat and mouse fun: https://breachinsider.com/blog/2017/credential-stuffing-how-...

From my experience, and this may be because of the industry I am working in, the overall idea is "dont". That is not to say that it doesn't work for other sectors & I'm pretty sure there are lots of evidence to say otherwise, but you should certainly consider if it is appropriate for your target market.

My cold outreach email campaigns have generally been met with silence, with the occasional response of "Looks great but not for us right now", or "We pick our own security tools, so if you show up in our research, we'll reach out to you".

Looking back on it, I completely agree with the responses I have had - if I was on their side of the fence, I would certainly just archive the email & ignore it. With this in mind, I think the effort is probably better spent doing research and content based marketing - getting eyes on your site and/or content for people who are clearly already interested in what you have to say or what you are up to.

Agreed, based on other thresholds and alerts, we certainly saw some more advanced actors - using in-country home broadband lines to conduct the attacks. This made tracking and blocking them much harder, as there was a risk of blocking genuine customers who simply didn’t conform to our idea of ‘normal’. We ended up finding another way to fingerprint them, but thank you for calling that out, as you are entirely right that there is almost always someone trying to be truly covert.

If anyone is suffering with these types of attacks (or isn’t and you think you’re missing something) feel free to reach out, more than happy to help - email is in my profile

If the term Credential Stuffing is new to anyone, we’ve done a deep dive into what it is and the tools that are used here: https://breachinsider.com/blog/2017/credential-stuffing-how-...

We saw this pretty regularly at my old job, with attacks almost daily. They range from ‘script kiddie’ who just use the default tool settings and do it all from one IP making it easy to spot, to persistent attackers who would play cat and mouse with our live defences. They’d switch IPs using huge proxy lists found online every few minutes, as well as learn our alerting thresholds and attempt to fly just under the radar. For some reason though, they always seems to user UserAgents that were ancient, or weren’t real, allowing us to identify attack traffic compared to our normal user activity.

Thanks for the Edgerouter link, saved me doing some Googling - Off to got and apply this now and see what difference this makes to the Bufferbloat tests.

As Arie mentions, this is a little more involved on the EdgeOS stuff, but doesn't look too complex for those that are used to a CLI or two.

Edit: Entirely off-topic, but an equally interesting find – There is a WireGuard client for the EdgeRouter line: https://community.ubnt.com/t5/EdgeRouter/Release-WireGuard-f...

From what I’ve read, this is exactly what I was thinking too - this has POS/till malware written all over it. I look forward to getting some of the more technical details (if they get realised) to see exactly how widespread this issue was.

I'm happy to be corrected here, but in response to:

I have to constantly be worrying about not putting "secret" things into the doc. Unless they have someone who's job is to take their real chat and transcribe it, in which case, that's great because that person is useful for a postmortem as well.

I think they did only have one person updating the document, from what I could as I was following the live updates - only very occasionally did I see someone other than 'Andrew' update the document.

A small suggestion, if I may - browsing your landing page, I found it would occasionally jump each time your ‘typing text’ changed towards the top of the page. You might want to set a static height on that div, or maybe just have a permanent zero-width space at the start of the div to give it a height when there aren’t any visible characters.

Or I suppose you could just tweak the JS so that it only runs when it is visible, otherwise it’s paused maybe?

This has definitely been the case for me over at breachinsider.com too – the ShowHN brought our first handful of customers, which have been a real delight to work with and completely fit the description outlined above... they understand the position we are in, and are happy to report issues or bugs they find (and are happy when we fix them in hours rather than weeks).

Generally speaking (and not in anyway a comment directed at the lovely people behind EnvKey), it can be a double edged sword, as if you are seen to only plug your business, even if you do add to the conversation, it can come across as a little disingenuous or pushy. So if you do take this route, don’t forget to be human and post normally sometimes.

I've started to take a look at the binary that was uploaded - it seems it wasn't just Gitea that got hit by this, but also https://github.com/opencompany/www.opencompany.org which too has a strange release associated with the repository.

My findings as they go are being shoved into a blog post: https://grh.am/2018/a-look-at-the-compromised-gitea-release/

What issues do you have with HTTPS/TLS? I can’t say I’ve come across any issues so far - is it a specific usecase to Ahrefs?

Same experience here - we run a docker instance of Chrome using tabs for multiple pages rather than multiple browsers, and they regularly run for days without issues. Of course their RAM usage gradually expands but it is easy enough to systematically stop & start the container, thanks to some built in error and fault handling to retry any requests which failed.

I can’t say I’ve seen one tab bring down the entire browser, but I’m sure thats feasible, but thanks to docker and the fault handling above, it’d restart the instance and be up within seconds.

Latency would be the big issue here. You’d likely have to spin up instances in lots of key data centres to try and combat this...

Each AWS location, each Google Cloud location.. and that’s not considering those that are colocating their own kit.

Interesting idea though, but you’d end up having to bundle it with DBaaS, at which point you’ve got the pressure and stress of having to look after everyone else’s data.

Would be interesting to know if they fit the ‘classic’ credential stuffing methodology (https://breachinsider.com/blog/2017/credential-stuffing-how-...) or if they have moved on to something more sophisticated.

My email is in my profile if you fancy talking specifics, would love to hear about what you’re seeing.

Spot on - they’re often referred to as ‘stressers’ or ‘booters’, and can make a nice chunk of money. There’s always someone looking to knock someone off of Xbox Live or PSN, or even chance it and try to take down a popular website. Depending on the technique used and the size of the botnet, you can cause some sysadmins or SOCs a headache.

I’m sure anyone else in the ISP industry will tell you that anytime kids are off school (summer holidays or half term here in the UK) the DDoS alerts go up a notch or two.

Not the owner - just wondered what the project was & figured I wouldn't be the only one to query it, seeing as we get linked to the release notes.

Personally I would pick Scrapy too, but it's good to have competition, and Colly looks like a nice addition to the family.

For those that haven’t heard of go-colly before, it’s a scraping platform written in, yup you guessed it, go. See: http://go-colly.org/

Here’s an example we can all relate to: http://go-colly.org/docs/examples/hackernews_comments/

Looks like you committed a .env file previously with some semi-private details contained within it, plus you’ve hardcoded some Cloudinary API credentials. You may want to rotate them before they’re abused by someone.

Edit: oh and some database credentials & getstream.io api credentials

I’m going to be cheeky and call out one of your edited points as something I focused on from the start.

As a bootstrapped SaaS owner myself, automating almost everything has been key, giving me time to go and work on other things that simply aren’t easily automated (I’m looking at you sales).

Somethings I have automated:

- Onboarding should be hassle-free with very little interaction needed from myself, unless they are after something bespoke. - Infrastructure is handled by Ansible, so I can easily (manually) scale up should I ever get a hug from HN. Also means I can rebuild from scratch relatively easily - just a few ansible commands. - Silly things that are easily forgotten like LetsEncrypt renewals, backups etc.

I’m sure there are other things but they evade me currently.

Surface Mounted Device/Technology (https://en.m.wikipedia.org/wiki/Surface-mount_technology)

Were they unique and/or generated passwords each time, or was it a password you have used else where?

It is unlikely to be a Spotify breach, but if the password was unique to Spotify then that certainly adds a little more weight to the argument.

Usually it is simply a case of ‘credential stuffing’, where other data breaches are checked against other common/popular websites, with the goal of finding accounts that work and can be sold to others for illegal use (TV streaming services etc.)

Overview of credential stuffing can be seen here: https://breachinsider.com/blog/2017/credential-stuffing-how-...

Zone transfers is one way, but you can also use brute force using a common word list. You can also these days use ‘OSINT’ (open source intelligence), and use things like TLS certificate transparency logs to go looking for obscure DNS names.

Would be interesting to know how they identified the breach. It is exactly these situations that I produced Breach Insider[0], in the hope to try and reduce the time to detection down from months to days.

Those of you affected by this breach, have you noticed any unusual spam/emails recently, that may be related to MFP? I’m wondering if they got the tip-off from their users.

[0] https://breachinsider.com

Awesome, glad you like it!

I’ve always had a good experience with fastmail.com, and I know it gets a lot of love here on HN.

$0.50/million requests, but it’s a minimum of $5/month (giving you 10million requests essentially.)

Not a criticism, this it looks like an excellent product for those who can benefit from it, just calling it out for others that read the comments here before the original content.

Looks like exactly what I would suggest, although I’d argue EC2 might be slightly overkill. You’d get more for your money with Linode/DigitalOcean/OVH or even Hetzner’s new cloud offering. Will help save some pennies early on.

Breach Insider is a one person bootstrapped company: https://breachinsider.com

Been live for a few months now and enjoyed finding the balance between sales and producing new features.

This has, similar to Meltdown and Spectre, been broken earlier than expected. As far as I am aware this wasn’t supposed to be released by Cisco until Wednesday, but anonymous reports started to circulate yesterday and today. This isn’t a great sign for the industry when stuff can’t be kept under wraps until an agreed date.

Edit: Credit to the folks at NCC Group - they’ve picked up a few ASA vulnerabilities now.