21–30 of 117 posts
Using "ufw" on a production server is an anti-pattern, in my opinion. You should use something like ferm instead.
Also, I do need to play with nftables.
> We had been relying on the firewall to provide protection against threats, but when the firewall silently failed, we were left exposed.
> a change needs to be made as to which database users have permission to drop the database
I think these two definitely highlight the importance of the always using the "layered onion" model of security.
The combination of a firewall, a password, and a nuanced permissions model would have been sufficient to mitigate the attack, even if one or both of the others failed simultaneously.
The most important bit of information the above chart shows us is what a full database transfer looks like in terms of bandwidth. From 6p to 9:30p, the amount of data was the expected amount from a working primary server with multiple secondaries syncing to it. At 3a, you’ll see an enormous amount of data transfered.
This tells us that the hacker was an automated digital vandal rather than a concerted hacking attempt. And if we were to pay the ransom, it wouldn’t do anything because the vandals don’t have the data and have nothing to release.
Great writeup! Writeups like these help everyone learn from each other's mistakes. > We had been relying on the firewall to provide protection against threats, but when the firewall silently failed, we were left exposed. > a change needs to be made as to which database users have permission to drop the database I think these two definitely highlight the importance of the always using the "layered onion" model of secu…
Lol, that’s the same footgun I discovered myself when was checking open ports. Who that wise guy in Docket team who decided to pass default firewall rules and open containers ports to public?
This is pure ignorance and slandering the Docker team for it seems weird.
Kinda weird to blame Docker. This is pure user error.
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…
Even in case we accidently violate some security rules (like open ports,...) the application is still safe ?
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…
Kinda weird to blame Docker. This is pure user error.
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).
https://twitter.com/joaoqalves/status/1332638533572550656?s=...