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.

▲

hypfer 3 hours ago | parent | next [-]

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.

▲

jsiepkes 3 hours ago | parent | prev | next [-]

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?

	▲	LoganDark 3 hours ago \| parent [-]
		> 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.

▲

tgv 3 hours ago | parent | prev | next [-]

Still, it doesn't have to ping back, and ssh can (should) be very restrictive.

	▲	Gigachad 2 hours ago \| parent [-]
		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.

▲

LoganDark 3 hours ago | parent | prev [-]

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!)

▲

darkwater 3 hours ago | parent [-]

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.

	▲	LoganDark 3 hours ago \| parent [-]
		h2o user doesn't have write access to anything on the system, not even its own config file. I don't think I disabled exec for it though. And I guess it could leak the HTTPS private key. FWIW sufficiently secured software doesn't need to be updated. Doesn't matter if it's old and unsupported if there are no vulnerabilities in it. That said, h2o is probably far from free of at least some vulnerabilities, not to mention all the layers below it. OpenSSL for example has had some vulnerabilities, and h2o depends on it. I'm not saying I exactly practice what I preach. h2o's definitely a choice, but realistically I doubt anything's going to happen that I really care about.