Do I Need to Harden SSH over Tor?

Comments

• marcos@lemmy.world ⁨7⁩ ⁨months⁩ ago

  If you don’t have any good reason not to, always set your SSH server to only authenticate with keys.

  Anything else is irrelevant.

  source

  • AbidanYre@lemmy.world ⁨7⁩ ⁨months⁩ ago

    If you don’t have any good reason not to

    Spoiler alert: you probably don’t.

    source

    • marcos@lemmy.world ⁨7⁩ ⁨months⁩ ago

      This is the internet. If you poke the bear, somebody will come-up with a completely reasonable use case of password authentication that happened once somewhere on the world.

      source

      • -> View More Comments
    • someonesmall@lemmy.ml ⁨7⁩ ⁨months⁩ ago

      30 character password + fail2ban after one failed attempt. Why not?

      source

      • -> View More Comments
• Audalin@lemmy.world ⁨7⁩ ⁨months⁩ ago

  Disabling root login and password auth, using a non-standard port and updating regularly works for me for this exact use case.

  source

  • tal@lemmy.today ⁨7⁩ ⁨months⁩ ago

    using a non-standard port

    It’s really not that hard to find SSH servers running on a non-standard port.

    nmap or a similar port-scanning software package can find ports listening for TCP connections. There are software packages – don’t recall names off-the-cuff, but I’m sure that you could go dig one up – that connect to ports and then aim to identify the protocol from a fingerprint out of a database that they have. The SSH protocol has a very readily-identifiable fingerprint, don’t even need specialized software.

    Let me just bounce to a machine as an example:

    $ telnet tals-host.tals-domain.com 22
    Trying tals-IP...
    Connected to tals-host.tals-domain.com
    Escape character is '^]'.
    SSH-2.0-OpenSSH_9.6p1 Debian-4
    ^]
    telnet> q
    Connection closed.
    $
    

    source

    • Getting6409@lemm.ee ⁨7⁩ ⁨months⁩ ago

      I feel like the argument for using a nonstandard ssh port these days is that you dodge the low tier automation/bots that are endlessly scanning IPs and port 22 and trying obvious usernames and passwords. I do also question how much it is worth dodging these since presumably you’d have already done the other basics like key only and no root login before this. Maybe there’s some value if you want a clean auth.log or equivalent

      source
• tal@lemmy.today ⁨7⁩ ⁨months⁩ ago

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

  source

  • anon2963@infosec.pub ⁨7⁩ ⁨months⁩ ago

    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.

    source
• dotslashme@infosec.pub ⁨7⁩ ⁨months⁩ ago

  There are several things you can and should do to harden your server, many of them can be found here.

  source
• Decronym@lemmy.decronym.xyz ⁨7⁩ ⁨months⁩ ago

  Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

  Fewer Letters	More Letters
  IP	Internet Protocol
  SSH	Secure Shell for remote terminal access
  TCP	Transmission Control Protocol, most often over IP

  ---

  [Thread #671 for this sub, first seen 10th Apr 2024, 23:55] [FAQ] [Full list] [Contact] [Source code]

  source