Hacker News Reader

Comment by LoganDark | Hacker News Reader

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.

View on HN

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.

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 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.

> 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.

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.

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.

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.

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.

Reply on news.ycombinator.com