Live data from Hacker News

Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

github.com

41–50 of 200 posts

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#41

That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?

I don't know why people knock on "security by obscurity" in general, it's a great defense for many threat models that an average individual would fall under. A lot of credential stealing viruses just look for specific folders or file names for examples, some vulnerability scanners look for specific ports, etc ...

It’s because they had some security experts say it (about things like moving your open mail relay to port 7384 to ‘secures’ it) and it’s the only thing they know about security.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#42
post #31
post #26

Earlier quoted context omitted.

Compared to just deploying totp normally as a PAM module this is a horrible idea. Much harder to ratelimit, much cheaper for the attacker to bruteforce codes. It’s neat for sure, but not a good defense.

Doesnt the TOTP in this case concern the listening port for sshd, so it doesnt actually touch the authentication in any way? Just switches the port in a TOTP’esque manner

This solution switches the listening address (IPv6 address), not the port.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#43

Make sure your time servers are configured correctly. My department had several Silicon Graphics workstations. Running IRIX, they machines determine amongst themselves which has the most accurate time and they vote that one as the Timemaster. Any new machines added would take their time from the Timemaster. The oldest machine was Timemaster and 8.5 minutes off. Took me week to figure out why my brand workstation had…

Man. Time based bugs are some of the worst. I spent weeks trying to figure out what was wrong with some of my scripts running under WSL. Apparently wsl Linux kernel had a bug that could cause time to drift by minutes.

This is why mission critical systems like Boeing airliners require a reboot. At some point it’s just a lot more practical and safer.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#44
post #33
post #2

Really cool idea. If someone is interested further in the general concept it is called ”moving target defense.”

It's also known as "security audit evasion" and is the kind of thing you might do to hide a hostile system on a network. You should never intentionally do it to your own systems. If you see something like this deployed assume it's either malice or laziness.

[deleted]

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#45

Make sure your time servers are configured correctly. My department had several Silicon Graphics workstations. Running IRIX, they machines determine amongst themselves which has the most accurate time and they vote that one as the Timemaster. Any new machines added would take their time from the Timemaster. The oldest machine was Timemaster and 8.5 minutes off. Took me week to figure out why my brand workstation had…

Man. Time based bugs are some of the worst. I spent weeks trying to figure out what was wrong with some of my scripts running under WSL. Apparently wsl Linux kernel had a bug that could cause time to drift by minutes.

My Windows 10 clock goes 2-5x faster when I hibernate and come back

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#46
post #31
post #26

Earlier quoted context omitted.

Compared to just deploying totp normally as a PAM module this is a horrible idea. Much harder to ratelimit, much cheaper for the attacker to bruteforce codes. It’s neat for sure, but not a good defense.

Doesnt the TOTP in this case concern the listening port for sshd, so it doesnt actually touch the authentication in any way? Just switches the port in a TOTP’esque manner

The point is that if the attacker somehold got hold of the primary login credentials (username + key/password), then they can easily bypass this scheme with a port/address scan. This can be done very quick[1] and is hard to rate limit. Furthermore, an attacker that can eavesdrop on the user's connections can infer the OTP since it's being transmitted in the open., but if it was done through a PAM module they wouldn't be able to because it's encrypted.

[1] https://nmap.org/book/synscan.html

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#47
Stop it with this cloak and dagger BS. Just set a shared secret on it: https://github.com/google/tcpauth

(Yes, MD5 is safe for this use)

With tcp MD5 your connection is even secured against an active attacker who can sniff. They can't inject, or even RST the connection. Even if they can sniff and spoof everything.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#49
Unlike port knocking (which folks seem to be mentioning a lot), this seems like it only has 1,000,000 possible locations that can rapidly be scanned.

Knocking has multiplicative growth and so many more possibilities.

Perhaps you could include honeypots in the IPv6 range where you’re not bound that block the user, but this seems less reliable overall.

I’m sure this is just great fun, but perhaps not something to think of as secure so much as a fun idea — to make it secure you might want to use a system more like knocking.

Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP

#50
post #46
post #31

Earlier quoted context omitted.

Doesnt the TOTP in this case concern the listening port for sshd, so it doesnt actually touch the authentication in any way? Just switches the port in a TOTP’esque manner

The point is that if the attacker somehold got hold of the primary login credentials (username + key/password), then they can easily bypass this scheme with a port/address scan. This can be done very quick[1] and is hard to rate limit. Furthermore, an attacker that can eavesdrop on the user's connections can infer the OTP since it's being transmitted in the open., but if it was done through a PAM module they wouldn't…

Both scenarios assume a pretty heavy compromise already in place before the ssh control starts crumbling
Post reply on HN