Hacker News Reader

> NewsBlur is useful, destroying it serves no purpose at all. And make no mistake: the hacker clearly aimed to simply destroy it and pretend they have copied the data, so they were more than willing to do just that, wanton destruction for a miserly amount of money. Whoever did this may think they're l33t and cool but I personally think they are utter trash.

I doubt this was even specifically targeted at NewsBlur. Reading the article it sounds like it's just an automated attack that scans for any open mongo servers on the internet and does the same thing to any of them. Not that that's any better, really.

Well, someone controls those tools and someone is on the receiving end of that bitcoin address.

That someone very likely doesn't care whose databases they break. The operation is probably automated and they try to ransom anyone with a broken server.

They'll just run the money through one of those mixing services and you'll never know where the money went.

It’s not better, but at least it wasn’t personal, which would be worse.

If we accept that this is the default state of the Internet (insecure) then I think it is a correct assumption and forces everyone to think twice before exposing anything to the Internet by default. Here the default Docker behaviour was very much at fault but also the assumption that a Linux level firewall is good for Docker. We have docker deployments that are completely hidden behind NAT in AWS and such things are a non issue.

exactly. ideally, accidentally exposing your db to the internet should be all but impossible

I have run into this firewall problem too (not in any sort of production environment, thankfully).

The problem is that your mental model of a firewall tends to be that it sits 'in front of' all applications on your machine. Docker breaks this assumption by implicitly inserting rules into iptables.

Worse still, if you then inspect the state of the firewall (using UFW), it does not show you any of the rules that Docker inserted, because those rules are on a separate iptables chain.

The problem, then, is the interaction between Docker and UFW. UFW is designed as a 'simple' frontend for iptables, for situations where the advanced configurability of iptables is unneccessary. If you manage the firewall using UFW, you are not really supposed to also inject 'raw' iptables rules, especially not on non-standard chains. However, this is exactly what Docker does.

Therefore, we end up in the hairy situation where Docker adjusts your firewall, but UFW does not provide any indication that anything has changed. Neither project considers this a bug, and they just point to each other for a solution.

Personally, I think it should be on Docker to, at the very least, throw up some warnings when it is about to change firewall rules, as this is clearly unexpected behavior for many users (despite Dockers claims to the contrary).

Docker is not implicitly doing anything. The user requested for the port to get published and so docker published it.

As nice as it would be for Docker to be more configurable in terms of where rules get inserted, that would not have helped here because the user already misconfigured things (should be using docker networks for db access). Technically docker even has a chain that you can throw rules into that will get hit before docker's rules... so it's there just very manual (instead of, say, having a ufw mode).

> The user requested for the port to get published and so docker published it.

Yes, which runs counter to how every other application works. If you ask, say, sshd to listen on port 22, your firewall will still sit in front of it, unless you explicitly poke a hole in it.

Listening on a port and opening a port are different things. `-p` is for opening ports. Docker is not listening on behalf of the application. It is routing traffic to the application.

Docker is implicitly overriding existing rules by putting their own ones in front. The least it should do is to put a warning "hey, there are other rules here,I'm adding my own, please verify.

It should also have option (I only found "complete on/complete off" one) to "just" create its DOCKER* chains and leave the jumping to them to the user

> I only found "complete on/complete off" one

Docker has a `DOCKER-USER` chain where the user can inject their own rules before docker's rules are run.

But even then, the user flat out should not be using `-p` unless they want to expose the service outside of the machine. That is the well documented networking model of docker. Docker also includes a network abstraction that should have been used here to give access to other services that need it and isolate it from the things that don't.

Which is a terrible solution no firewall manager would support

I am also puzzled that a firewall rule would be the only thing protecting user data. If any machine behind your NAT gets compromised then it is open buffet to the attackers (in addition to a misconfigured NAT like in this example). It is a bit shocking that it is 2023 and people are still doing that.

Perhaps security should be the next innovation. But I don't think it will be a technical innovation: there's enough tech and know-how to keep script-kiddies out. It's the lack of interest, the hunt for the MVP, the break-fast culture.

> I personally think they are utter trash.

In this case, even criminal, given the extortion attempt.

> there's enough tech and know-how to keep script-kiddies out

I think that this is true for the parties that have the budget for a proper security team. But your average programmer is not able to keep up with both the very rapid evolution of the security scene, a bunch of tooling to build their application with (backend, frontend) and then the burden of writing the application itself. Even with an interest, and without the urge for an MVP or the subscription to 'break-fast' you are essentially a sitting duck given enough time. After all there is an army of attackers out there and you are just you.

I have a ton of ideas of how I could make my current project much better by adding a service. But I'm not going down that route because I know I will inevitably end up in an arms race that will stop me from being able to focus on the application and that will shift more and more resources to the security domain. So instead the app is limited in functionality and only works using local storage in the browser, everything else is utterly static. It's a dumb and very much brute force solution but it works. It is also severely limiting.

It was amazing how open things were back in the day. Whitehouse.gov had an open mail relay that I enjoyed sending mail through.