> "None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet."
This prompts a reflection about, as an industry, we should make a better job in providing solid foundations.
When I check tutorials on how to drill in the wall, there is (almost) no warning about how I could lose a finger doing so. It is expected that I know I should be careful around power tools.
How do we make some information part of the common sense? "Minimize the surface of exposure on the Internet" should be drilled in everyone, but we are clearly not there yet
I don't think it's that unreasonable for a database guide not to mention it. This is more of a general server/docker security thing. Just as I wouldn't expect an application guide to tell me not to use windows xp because it's insecure.
Most general guides on the other hand regarding docker mention not to expose containers directly to the internet and if a container has to be exposed to do so behind a reverse proxy.
> if a container has to be exposed to do so behind a reverse proxy.
I see this mentioned everywhere in the comments here but they seem to miss that the author explicitly wanted it to be exposed, and the compromise would have happened regardless if the traffic went directly to the container or via a reverse proxy.
The proper fix for OP is to learn about private networks, not put a reverse proxy in front and still leave it running on the public internet...
> When I check tutorials on how to drill in the wall, there is (almost) no warning about how I could lose a finger doing so. It is expected that I know I should be careful around power tools.
I think the analogy and the example work better when the warning is that you should be careful when drilling in walls because there may be an electrical wire that will be damaged.
To your point, guides don't warn too much about electrical wires because code and practices makes it really hard to do. Code requires metal plates where electrical wires go through studs so you can't drill into them, and every stud finder in existence these days also detects AC behind them.
We didn't make the guides better, we made the tradespeople make it so any novice can't burn down the house by not following a poorly written tutorial.
If we're being pedantic, then I'd say "old stud finders" are still being sold (second hand for example), so "every stud finder for sale these days" isn't correct either.
Best to just say "most" or "some" to cover all corner cases :)
Probably the "we can do everything and anything right now easy peasy, for serious of just just for the heck of it" attitude needs to be dialed down. The industry promises the heavens and devilish charm while releasing not even half cooked unnecessary garbage sometimes, that has bells and whistles to distract from the poor quality and not thought through, rushed illusions, that can chop all your imaginary limbs off in a sidestep or even without complete uninterrupted attention.
Things potentially making big trouble like circular saw tables have prety elaborate protection mechanisms built in. Rails on high places, seatbelt, safety locks come to mind as well of countless unmentioned ones protecting those paying attention and those does not alike. Of course, decades of serious accidents promted these measures and mostly it is regulated now not being a courtesy of the manufacturer, other industries matured to this level. Probably IT industry needs some growing up still and less children playing adults - some kicking in the ass for making so rubishly dangerous solutions. Less magic, more down to earth reliability.
Between MongoDB running without a password by default and quick start guides brushing over anything security related, the industry can use a more security-conscious mindset.
However, security is hard and people will drop interest in your project if it doesn't work automatically within five minutes.
The hard part is at what experience level the warnings can stop. Surely developer documentation doesn't need the "docker exposes ports by default" lesson repeated every single time, but there are a _lot_ of "beginner" tutorials on how to set up software through containers that ignore any security stuff.
For instance, when I Google "how to set up postgres on docker", this article was returned, clearly aimed at beginners: https://medium.com/@jewelski/quickly-set-up-a-local-postgres...
This will setup a simply-guessable password on both postgres and pgadmin, open from the wider network without warning. Not so bad when run on a VM or Linux computer, quite terrible when used for a small project on a public cloud host.
The problems caused by these missing warnings are almost always the result of lacking knowledge about how Docker configures it networks, or how (Linux) firewalls in general work. However, most developers I've met don't know or care about these details. Networking is complicated beyond the bare basics and security gets in the way.
With absolutely minimal impact on usability, all those guides that open ports to the entire internet can just prepend 127.0.0.1 to their port definitions. Everyone who knows what they're doing will remove them when necessary, and the beginners need to read and figure out how to open ports if they do want them exposed to the internet.
That's an interesting take away, I just quoted the exact same line from the blob to a friend with my response being
> why didn't somebody stop me?!
I'm not sure if "the industry" has a problem with relaying the reality that: the internet is full of malicious people that will try to hack you.
My take away was closer to. The author knew better but thought some mix of 1) no one would provide incomplete information 2) I'm not a target 3) containers are magic, and are safe. I say that because they admit as much immediately following.
> Ofcourse I password protected it, but seeing as it was meant to be temporary, I didn't dive into securing it properly.
Just like people shouldn't just buy industrial welding machines, SCUBA equipment or a parachute and "wing it" I think the same can be said here.
As a society we already have the structures setup: The author had been more than welcome to attend a course or a study programme in server administration that would prepare them to run their own server.
I myself even wouldn't venture into exposing a server to the internet to maintain it in my freetime, and that is with a post graduate degree in an engineering field and more than 20 years of experience.
> Just like people shouldn't just buy industrial welding machines, SCUBA equipment or a parachute and "wing it" I think the same can be said here.
I find this to be extremely sad.
Unlike welding or diving, there is no inherent physical risk to life and limb to running a server. I should be able to stand up a server and leaving it running, unattended and unadministered, and then come back to it 20 years later to find it happily humming along unpwned. The fact that this isn't true isn't due to any sort of physical inevitability, it's just because we, the collective technologists, are shit at what we do.
No. It's not so easy because in most cases you have to choose between security, flexibility and usability. Obviously it's not a 100% accurate example but generally speaking, it tends to be true. Sum it up over several decades of development and you get why we cannot have something that it's really really easy to use, flexible and secure by default.
Which would help exactly 0 in this scenario, where someone is exposing a port directly on the Internet. Also, FreeBSD is even more niche than Linux, I doubt it would stand the average user stress test.
Absolutely it would because jails doesn't do weird shit like this from the get go.
With FreeBSD, you have to deliberately open ports, not the other away around.
I don't understand your second sentence.
"average user stress test"??
> With FreeBSD, you have to deliberately open ports
The issue outlined in the article happened because the author deliberately open their service to the public internet. Replacing Linux with FreeBSD wouldn't have prevented the compromise.
What motivates this attitude? Software, like anything else, needs to be actively maintained. This is a positive sign of technology evolution and improvement over time. To expect to run some software for 20 years without needing to apply a single security patch is ridiculous, and probably exactly the attitude that caused the author to get himself in this situation.
> To expect to run some software for 20 years without needing to apply a single security patch is ridiculous
The whole point of my comment is that it's only "ridiculous" because of path dependency and the choices that we have made. There's no inherent need for this to be true, and to think otherwise is just learned helplessness.
Better security design fixes this. Sandstorm fixed this for self-hosters ten years ago (Sandstorm is designed to run unmaintained or actively malicious apps relatively safely), but people are still choosing the quick and easy path over the secure one.
Sandstorm has been part of my selfhosted stack since it was a start-up, and it has worked for a decade with virtually zero attention, and no exploits I am aware of.
If there are other hosted apps that want a really easy on-ramp for new users: packaging for sandstorm is an easy way to create one.
>Unlike welding or diving, there is no inherent physical risk to life and limb to running a server.
good news! there is no inherent risk to life or limb because you left your server exposed. As OP discovered, you might come back to find it running a crypto miner. and that's just really not that big of a deal. maybe we're not all shit at what we do, but rather we have appropriately valued the seriousness of the risks involved, and made the decision that locking everything down to be impossible to hack isn't actually worth the trade-offs to usability, convenience, and freedom.
you can leave your iPad running, unattended, and unadministered for 20 years if that's what you wanted, and come back to find it un-pwned.
> stand up a server and leaving it running, unattended and unadministered
to, what was my proposition, maintain a server with active access from the internet.
Just what you describe I do myself: I have several home server running, but none accept incoming connections from the internet and the sec surface is much smaller.
You can't just click a few buttons and have industrial machinery - and when you DO get it there's a ton of safety warnings on and around it. And I don't agree with your fundamental premise; self owned computing should be for everyone. It shouldn't be - at least for some subset of basics - arcane or onerous.
Like you sibling I think you also misunderstand my statement: I do run local servers, but none a connected to the internet.
I definitely believe it is for all to have a NAS server, a home assistant, or a NUC setup to run some docker containers.
Just don't let them accept connections from the internet.
For most normal home setups it is actually super hard to make them accept incoming requests as you need to setup port forwarding or put the server in front of your router.
The default is that the server is not reachable from the internet.
You've introduced a new element here - the credit card. And if you did have the money and whimsy it'd still show up with (regulated, mandatory, industry-standardized) safety documentation.
The credit card (or rather, money) was required to purchase the computer, much like it’s required to purchase other power tools or industrial machinery
I guess that depends where you order from. You can get some crazy machines from Alibaba/Aliexpress and the “documentation” they come with is usually… well it leaves a lot to be desired.
And yet, OP here seems very comfortable with computer stuff. Can’t imagine about the regular joe buying a nas from synology and all the promesses made by the company.
It is widely known not to expose anything to the public internet unless it's hardened an/or sandboxed. A random service you use for playing around definitely does not meet this description and most people do know that, just like what a power tool can do with your fingers.
This prompts a reflection about, as an industry, we should make a better job in providing solid foundations.
When I check tutorials on how to drill in the wall, there is (almost) no warning about how I could lose a finger doing so. It is expected that I know I should be careful around power tools.
How do we make some information part of the common sense? "Minimize the surface of exposure on the Internet" should be drilled in everyone, but we are clearly not there yet