If I use SSH as a Tor hidden service and do not share the public hostname of that service, do I need any more hardening?
Full Post:
I am planning to setup a clearnet service on a server where my normal “in bound” management will be over SSH tunneled through Wireguard. I also want “out of bound” management in case the incoming ports I am using get blocked and I cannot access my Wireguard tunnel. This is selfhosted on a home network.
I was thinking that I could have an SSH bastion host as a virtual machine, which will expose SSH as a a hidden service. I would SSH into this VM over Tor and then proxy SSH into the host OS from there. As I would only be using this rarely as a backup connection, I do not care about speed or convenience of connecting to it, only that it is always available and secure. Also, I would treat the public hostname like any other secret, as only I need access to it.
Other than setting up secure configs for SSH and Tor themselves, is it worth doing other hardening like running Wireguard over Tor? I know that extra layers of security can’t hurt, but I want this backup connection to be as reliable as possible so I want to avoid unneeded complexity.
I think that SSH, hidden or no, is fine. It’s intended to be Internet-facing and secure.
All that being said, we did just infamously have the Jia Tan/xz attack, an attempt to stick a backdoor spanning many Linux distros.
Also, I would treat the public hostname like any other secret, as only I need access to it.
If you’re worried about someone malicious having access to your network connection, ssh is going to do a DNS lookup to map the hostname to an IP for the client.
Other than setting up secure configs for SSH and Tor themselves, is it worth doing other hardening like running Wireguard over Tor? I know that extra layers of security can’t hurt, but I want this backup connection to be as reliable as possible so I want to avoid unneeded complexity.
If you’re going to be running multiple layers of software, keep in mind that compromising the outer layer – whether it’s a port-knocking system, a VPN like Wireguard, some sort of intrusion detection system that inspects packets prior to them hitting the rest of the system, etc – can be equivalent to compromising the inner. And attackers have aimed to exploit things like buffer overflows in IDSes before – this is a real thing. So if, for example, there is a Wireguard exploit, it may permit the same sort of compromise that a compromise of sshd does if gaining control of the Wireguard software is as severe as gaining control of the sshd software. So if you’re wanting to add another layer and your goal is that compromise of the first layer still leaves another layer to get through, you may want to structure things such that compromise of the VPN software doesn’t compromise anything further.
Thanks for the wise words. However I have some questions:
If you’re worried about someone malicious having access to your network connection, ssh is going to do a DNS lookup to map the hostname to an IP for the client.
Are you sure that this is true for Tor? .onion addresses never resolve to an IP address, even for the end user client. If I was on an untrusted network, both for the client and the server, the attacker could find out that I was using Tor, but not know literally anything more than that.
And attackers have aimed to exploit things like buffer overflows in IDSes before – this is a real thing.
I would expect an IDS to be an order of magnitude larger attack surface than Wireguard, and significantly less tested. Although I could also say that about SSH, and we had the recent backdoor. However, I think it is a lot more likely that a bug will cause a security method to be ineffective than actively turn it in to a method for exfiltration or remote access though. For example, with the recent SSH backdoor, if those servers had protected SSH behind Wireguard then they would have been safe even if SSH was compromised.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
I think that SSH, hidden or no, is fine. It’s intended to be Internet-facing and secure.
All that being said, we did just infamously have the Jia Tan/xz attack, an attempt to stick a backdoor spanning many Linux distros.
If you’re worried about someone malicious having access to your network connection, ssh is going to do a DNS lookup to map the hostname to an IP for the client.
If you’re going to be running multiple layers of software, keep in mind that compromising the outer layer – whether it’s a port-knocking system, a VPN like Wireguard, some sort of intrusion detection system that inspects packets prior to them hitting the rest of the system, etc – can be equivalent to compromising the inner. And attackers have aimed to exploit things like buffer overflows in IDSes before – this is a real thing. So if, for example, there is a Wireguard exploit, it may permit the same sort of compromise that a compromise of sshd does if gaining control of the Wireguard software is as severe as gaining control of the sshd software. So if you’re wanting to add another layer and your goal is that compromise of the first layer still leaves another layer to get through, you may want to structure things such that compromise of the VPN software doesn’t compromise anything further.
Thanks for the wise words. However I have some questions:
Are you sure that this is true for Tor? .onion addresses never resolve to an IP address, even for the end user client. If I was on an untrusted network, both for the client and the server, the attacker could find out that I was using Tor, but not know literally anything more than that.
I would expect an IDS to be an order of magnitude larger attack surface than Wireguard, and significantly less tested. Although I could also say that about SSH, and we had the recent backdoor. However, I think it is a lot more likely that a bug will cause a security method to be ineffective than actively turn it in to a method for exfiltration or remote access though. For example, with the recent SSH backdoor, if those servers had protected SSH behind Wireguard then they would have been safe even if SSH was compromised.