Comment by LoganDark
8 hours ago
It's just the same advice as ever: be extremely, exceedingly careful in what you expose to any network. When I set up machines for production, they don't respond to pings and they don't even have an SSH port open without knocking. There are also ways to eschew the need for an SSH port entirely.
People who never took that seriously will never take this seriously either, and that's their loss. (And loss of the commons, unfortunately.)
There's just also new advice: you can't afford to expose an unsecured system to the internet even for a moment. Think of those IPv4 address space scanners, except this time any one of them could be capable of developing individualized attacks in mere minutes. They don't sleep, they don't take breaks.
That’s fine for your home server, but if you want an actual server that the general public can use, it has to be exposed to the internet.
Sure, but still, attack surface could and should be minimized by rethinking what exactly even needs to be on a server the general public can use.
There are a lot of security problems you can categorically rule out by simply not involving a cloud. Clouds have been involved in a lot of things, because everyone was doing it, and because that's how you can collect rent, but they aren't really necessary for most use-cases.
So we could definitely get the exposure down there. We'd just have to fundamentally shift the defaults of this industry.
But not everything needs to be directly exposed to the internet. Framework had their data leaked because their metabase instance was hacked with a zero-day. Why was it directly exposed to the Internet? Why not require the use of a VPN like a Wireguard based solution or Nebula for these "internal" kind of apps?
> Framework had their data leaked because their metabase instance was hacked with a zero-day.
No, Framework had their data leaked because they stored it in the cloud with Metabase the company, which got hacked. Not because of any vulnerability on-premises.
Still, it doesn't have to ping back, and ssh can (should) be very restrictive.
Ping and ssh are pretty much never the things being hacked though. Turn password auth off and it’s very secure.
What gets hacked all the time is the actual web app itself. Which has to be exposed to be useful.
I didn't say there are zero ports open, they're not my home server, I just said they're production servers. But exposing something like a properly configured nginx to the internet is way different from exposing application code directly. Most of my servers have used h2o (built from source because they don't cut releases anymore?) because I wanted HTTP2 and HTTP3 before anyone else would get their act together. These days I still use h2o because I like the config better than nginx, even though it's a pain to set up because nobody packages it (and they don't cut releases!)
And then somebody driving an LLM will find your old and unsupported (how secure!) h2o server, find a 0day path traversal or RCE and own you.
1 reply →
So how do you expose your legitimate service on the Internet?
By opening a port to a secure application. A secure application is usually one I wrote from scratch or one that's been battle-tested and hardened enough that even new vulnerabilities are not very useful.