4 ms·

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.

tgv 1mo ago
Still, it doesn't have to ping back, and ssh can (should) be very restrictive.
- Gigachad 1mo ago
  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.
  - tgv 1mo ago
    I imagine it pays off to find weaknesses in openssl and sshd and the other gateways. There are some ubiquitous web frameworks, but ssh is nearly universal.
  - LoganDark 1mo ago
    > Turn password auth off and it’s very secure. Password auth and the root username. Use one attackers are unlikely to guess and elevate with sudo if needed.
hypfer 1mo ago
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 1mo ago
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 1mo ago
  > 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.
LoganDark 1mo ago
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 1mo ago
  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 1mo ago
    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.

tgv 1mo ago

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

Gigachad 1mo ago
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.
- tgv 1mo ago
  I imagine it pays off to find weaknesses in openssl and sshd and the other gateways. There are some ubiquitous web frameworks, but ssh is nearly universal.
- LoganDark 1mo ago
  > Turn password auth off and it’s very secure. Password auth and the root username. Use one attackers are unlikely to guess and elevate with sudo if needed.

hypfer 1mo ago

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 1mo ago

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 1mo ago
> 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.

LoganDark 1mo ago

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 1mo ago
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 1mo ago
  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.