Re:Hacker deleted all of NewsBlur’s Mongo data and is now ho...
by discordance on Thursday June 24, 2021 @02:14AM
(#27614499)
Defense in depth... VNets, TLS certs, RBAC etc.
Re:Hacker deleted all of NewsBlur’s Mongo data and is now ho...
by AtNightWeCode on Thursday June 24, 2021 @06:05AM
(#27615705)
Layer 4 and/or 7 proxies -> private networks -> services. Auth and encryption all the way on everything. IP white-listening were suitable. Pretty much the standard way of building web were I live.
Re:Hacker deleted all of NewsBlur’s Mongo data and is now ho...
by lima on Thursday June 24, 2021 @11:58AM
(#27619488)
"Private subnet" is just one way to accomplish it - what you want is a firewall that drops inbound traffic by default, and private subnet/NAT is one common way to do it that does have some downsides (extra complexity - you need a NAT gateway now).
Re:Hacker deleted all of NewsBlur’s Mongo data and is now ho...
by mtippett on Thursday June 24, 2021 @01:32AM
(#27614282)
+1 on the private subnet.
You want to design your system so that if a network a critical misconfiguration occurs you don't open yourself up - you simply stop working.
(Too many years chasing EMR clusters getting dropped onto the internet by users with AWS console access).
In general, put everything in private subnets, and make the only way any traffic can get to a server is through a load balancer. There are very few reasons to have a server itself have its own public IP address, and using your load balancer as a chokepoint, means you can set up layers and layers of redundancy to prevent traffic from ever being able to reach a database under your control.
This holds true whether we're talking RDS DBs, something you've spun in a K8 cluster, or something you're running on a vanilla compute box.
Assume you will screw up at some point and open up a port that shouldn't be. Ask yourself, "what's the impact here?" If you're OK, even with a fat fingered port, great.
Assume you will have a dev deploy a DB without a password. "What's the impact here?" If you're ok, even without a password, great!
That isn't to say that the above two scenarios are something you should tolerate, but automation can help detect these sorts of issues and make it easy for you to resolve them. While that automation is running, you want to make sure you're not going to get owned.
Kudos to the OP for sharing their story. Always lots to learn on this front, and we can always get better at our cloud operations.