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
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.
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.
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.
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.
The best way to learn is to do. Sure, you might make some mistakes along the way, but fuck it. That’s how you learn.
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.
Slightly pedantic point of order: you mean to say every stud finder for sale these days, not in existence, for the old stud finders still exist.
Okay, that's all. Carry on.
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.
Here is the fundamental confusion: programming is not an industry, it is a (ubiquitous) type of tooling used by industries.
Software itself is insecure in its tooling and in its deployment. So we now have a security industry struggling to improve software.
Some software companies are trying to improve but software in the $cloud is just as big a mess as software on work devices and personal devices.
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...
I don’t think imperfection is a choice we’ve made. I think imperfection is part of our nature.
That said, the current state of software development is absolutely a choice, and a shockingly poor one in my opinion.
That sucks, because that means anything built not to that standard (which I guess is a US one?) could lead the person to hurt themselves/the house.
One doesn't exclude the other, and most likely both are needed if you're aiming to actually eliminate the problem as well as you can.
Best to just say "most" or "some" to cover all corner cases :)
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.
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.
It's not hackable though in the original sense of the word, so not interesting the crowd at HN. Docker is, for everybody, good and bad.
> 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.
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.
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.
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.
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.
> 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.