41–50 of 117 posts
This is why you shouldn't be using Docker in production. It's a great tool, but it's simply not designed for that kind of environment. Edit: note I said Docker specifically, nothing about containerization.
This is why you shouldn't be using Docker in production. It's a great tool, but it's simply not designed for that kind of environment. Edit: note I said Docker specifically, nothing about containerization.
It's a pity that the chances of nailing the perps is so low. Obviously docker and the person that put this together share some of the blame but: the original internet would have never gotten off the ground if it wasn't for people cooperating with each other rather than to try to tear things down all the time. And with the chances of your average script kiddie/hacker/idiot getting caught being lower than a typical bik…
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.
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's a pity that the chances of nailing the perps is so low. Obviously docker and the person that put this together share some of the blame but: the original internet would have never gotten off the ground if it wasn't for people cooperating with each other rather than to try to tear things down all the time. And with the chances of your average script kiddie/hacker/idiot getting caught being lower than a typical bik…
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…
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).
It's a pity that the chances of nailing the perps is so low. Obviously docker and the person that put this together share some of the blame but: the original internet would have never gotten off the ground if it wasn't for people cooperating with each other rather than to try to tear things down all the time. And with the chances of your average script kiddie/hacker/idiot getting caught being lower than a typical bik…
> 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. Rea…
It's a pity that the chances of nailing the perps is so low. Obviously docker and the person that put this together share some of the blame but: the original internet would have never gotten off the ground if it wasn't for people cooperating with each other rather than to try to tear things down all the time. And with the chances of your average script kiddie/hacker/idiot getting caught being lower than a typical bik…
Earlier quoted context omitted.
Yes it's user error, but it's also a nasty trap for users who are not careful. And it hurts the most, where people are most likely to make the mistake (developers need to publish ports to access local containers on their development machines, but must take care not to do so when deploying to production).
Use `docker network` or the equivalent in the docker-compose file. Not taking time to think about how the software works is not the fault of the software.
docker listens on port X. Accessible on machine. Also accessible from outside regardless of ufw.
No amount of time and experience will make you think that configuring a software to listen on a port will automagically poke a hole in the firewall.
Earlier quoted context omitted.
Yes it's user error, but it's also a nasty trap for users who are not careful. And it hurts the most, where people are most likely to make the mistake (developers need to publish ports to access local containers on their development machines, but must take care not to do so when deploying to production).
Use `docker network` or the equivalent in the docker-compose file. Not taking time to think about how the software works is not the fault of the software.
What's wrong with "users should be careful" and "software shouldn't contain footguns"?
Earlier quoted context omitted.
> 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. Rea…
Well, someone controls those tools and someone is on the receiving end of that bitcoin address.
You should consider yourself lucky that you didn't lose your users data. My 2c: - NEVER expose a database to the public. Use at least a micro-service BFEs that do exactly what the app needs and nothing more. - Use a load balancer/gateway between your servers and the outside world (only port 80 and 443 should be open, 80 should redirect to 443). - Use Docker-(Compose) as runtime/orchestrator only for development. For…
They didn't intentionally expose the database; they thought that it was safe and docker bypassed their security.
> because IMHO the whole thing is your fault
How so? They had a working firewall, and then docker bypassed it, which they had no way of knowing to expect.