3 ms·
My thought on networking is to make sure you only expose SSH and HTTPS; firewall everything else off. SSH seems like a constant source of problems for people n
by jrockway 4y ago
My thought on networking is to make sure you only expose SSH and HTTPS; firewall everything else off. SSH seems like a constant source of problems for people new to running servers; within seconds of your server coming online, people will be trying to guess usernames and passwords. Configure it so you can't log in as root, and you can only authenticate with a key. These folks will never guess your key in a billion years (though obviously, don't leak it or something). I wouldn't bother with the complexity of fail2ban. If you have some out-of-band virtual console, you might not even need SSH, but it will be nice to have for git clones if you're self-hosting repositories. Totally reasonable to have SSH exposed to the Internet, in my opinion.
For HTTPS, run everything through a proxy, and maintain detailed access logs. Put your other services behind that proxy, and have them listen on 127.0.0.1 and not 0.0.0.0 (not that it really matters because you firewalled off all connectivity like that). Your HTTPS proxy should handle certificate provisioning for you. There are many options out there; I use Envoy, the self-hosting types should use Caddy or similar.
Anything that you expose to the Internet on a well-known port with an easy-to-guess password will be hacked instantly; SSH, MySQL, Wordpress, you name it, they'll own it. Seriously, your mind will be blown and your head will spin. Reduce the number of network ingress points to the bare minimum (though firewall rules), make sure absolutely everything not hardened is behind auth, and log aggressively so you can see what happened when something goes wrong.
I don't know what the state of the art these days is for auth. I wrote my own thing that uses WebAuthn; most people are probably using something like Keycloak. The Tailscale idea is also good; if you don't need this stuff on the Internet, then only put it on the Tailnet and let them handle auth.
- kickaha 4y agoAnother example of just the kind of concrete answers I was hoping for.
- 3np 4y agoOnce you have a stable setup you could even shut off public SSH and instead have it available only over Wireguard (I saw you already mentioned Tailscale). Tor Hidden Services are also an option that are straightforward to set up (you don't even need to think about fw/nat as long as you have tor access) but a bit off gaps in terms of recent accessible docs. If comments indicate interest I may get around to publishing some stuff on that lying around in the drafts folder.
- brokenmachine 4y agoRegistering interest!
- b0afc375b5 4y ago> Put your other services behind that proxy, and have them listen on 127.0.0.1 and not 0.0.0.0 Apologies for this newb question, but if you will be adding a proxy, aren't you required to bind it to 0.0.0.0, since if you bind it to 127.0.0.1, only a request within the service's host will be able to receive a response? I'd like to know what I'm misunderstanding here.
- adamckay 4y agoThey're saying bind the services to localhost so they're only accessible via the proxy. "Put your other services behind that proxy, and have [the services] listen on 127.0.0.1 and not 0.0.0.0"
- b0afc375b5 4y agoAh I see, I assumed it would be a multihost setup.
- mqus 4y agoAnother tip: change the port of your ssh server. This makes connecting a small bit more tedious(create a .ssh/config file on your clients!) But in exchange you gain much less people trying to hack your machine. This should not be your only security measure though, since its still findable for some people willing to put in the effort (or targeted attacks).