That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?
security by obscurity and defense in depth are synonyms.
Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
51–60 of 200 posts
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#52Earlier 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
This solution switches the listening address (IPv6 address), not the port.
Indeed you are correct.. Fruits of multitasking..
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#53Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#54That’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 ...
I view it as a cost-benefit analysis between implementing security by obscurity versus actual security. If you have real security, then you don't need security by obscurity. If you have security by obscurity, you still need real security. So it's obvious which is a better ROI. That's not to say security by obscurity layered on top can't be useful, such as filtering out noise, but I think the point most people are trying to make is "this thing is not a solution to your security problem, it is a potentially dangerous distraction".
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#55And all you have to do is trust that your client and server will always have synchronized clocks...
I'm not sure how you could really run a server environment of any size without that
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#56Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#57There should be no need to do this if you have a properly configured public/private key auth setup and disable password based login. And of course keep up to date on openssh patches and security advisories. I worry that something like this will provide a false sense of security for people who might ignore other more common-sense, fundamental precautions first.
Before doing something like this I would worry a lot more about client endpoint security (exactly to what level do you fully trust all the people and workstations/laptops that are authorized to ssh to this thing?), as an overall more likely threat.
There are also lots of less esoteric ways to not have a system listen on any publicly accessible IP address whatsoever. If it's really something critical you should be looking at a combination of making it purely an intranet service only, listening on an IP in an internal network block that isn't accessible from global routing tables at all. Or is completely firewalled off from the world, and only accessible once you've authenticated yourself to your VPN. Or only reachable once you first authenticate (public/private keys, two factor crypto key auth, etc) to a bastion host, and then reach the system from the bastion.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#58Make 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.
Oohh, are we doing time bugs? Sun T4 servers around early 2010s, and I forget which Solaris release this was, had a beaut of a random clock jump.
Every now and then, certain apps on the a system would crash around the same time. We'd scrape through the logs and usually see our app cratered, some databases, ntpd, sshd naturally. Logging of timestamps was iffy, obviously.
The ntpd was the obvious suspect because, despite keeping a nice low offset to its peers like 1ms or two, for months at a time, out of the blue it would confess something like "time offset is too large, I can't fix that so I'll exit!". After chasing Sun ntpd bug reports[1] for a while, we ruled it out when we saw a pattern in the undamaged logs that looked like
09:59:58.000 ...
09:59:59.123 ...
09:09:01.345 ...
09:09:02.123 ...
After some Sun support and some sunbugs searching [1 again] we found the T4 in that Solaris rev had a hardware RTC with separate registers for H, M, S etc and a write mutex protecting them, but no read mutex. It was possible to read the RTC while it was being updated, which happened when it was syncing the OS clock to the RTC, or something like that. Fixed in a later release.
1: RIP sunbugs database. It was such a mature relationship where Sun would let everyone see what they were working on and customers could participate or at least know about known issues. I would love to find an archive. Of course Oracle shut that off immediately so you had to open a ticket and ask.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#59That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?
Security by obscurity is when you hide implementation details to improve security. Secrets are not obscurity, randomness is not obscurity.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#60It all depends on your constraints and who needs SSH access, but if you're like me, you (1) have a number of personal VM instances on major cloud providers and (2) don't want to deal with anything but 'vanilla' Linux and sshd. No customizing kernels, no portknocking, no TCP wrappers, no fail2ban, no VPNs (not even tailscale which is very nice).
The approach that I've been using for about a decade is a script that gets your current (internet facing) IP and then uses a cloud API credential to add that IP to the cloud provider's firewall as a valid source IP to port 22. The API security and cloud firewall implementation is left to the major cloud providers (and they are very good at these things).
I run it manually whenever I'm in a new location or in the rare cases my home IPs change. You can add the IP to the list or replace the list each time. Or clean it up after a trip with a separate CLI flag. I figured one day I would automate it to track IPs, run constantly, and trigger the change if it detected a new IP - but that day never came because it never annoyed me (ymmv).
This approach could be extended to teams, but there are more details to think through about API permissions, etc.