[deleted]
Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
71–80 of 200 posts
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#72It 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 get…
Can I ask why you don't trust running fail2ban on 'cloud' based VMs? The defaults for how long it will ban failed ssh attempts are quite sensible, and short enough to prevent you from accidentally locking yourself out for a very long period of time (automatic unban time to remove iptables rules). If nothing else, it serves the useful purpose of stopping the log files from being cluttered up with various botnets' full…
It's not really about trust, it's about the hassle of adding and maintaining things (including keeping up with their changelogs and security issues).
As for log clutter, my approach comprehensively stops the logs files from being cluttered with failed attempts; that's one of the main reasons I do it.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#73Stop 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.
Is this just spiped with MD5 instead of HMAC-SHA256?
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#74Would this potentially leak consecutive TOTPs to an attacker who connects to all 1,000,000 or so possible addresses at 30 second intervals (and records the one that responds)?
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#75Earlier quoted context omitted.
Can I ask why you don't trust running fail2ban on 'cloud' based VMs? The defaults for how long it will ban failed ssh attempts are quite sensible, and short enough to prevent you from accidentally locking yourself out for a very long period of time (automatic unban time to remove iptables rules). If nothing else, it serves the useful purpose of stopping the log files from being cluttered up with various botnets' full…
It's not really about trust, it's about the hassle of adding and maintaining things (including keeping up with their changelogs and security issues). As for log clutter, my approach comprehensively stops the logs files from being cluttered with failed attempts; that's one of the main reasons I do it.
That is a good point but I should also add that fail2ban as a daemon and its default configuration to watch log files for other popular daemons (example: a postfix smtp traffic log) has changed very, very little in the past 5-6 years. It's not very much of a concern in terms of keeping track of configuration changes in major system upgrades.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#76Stop 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.
If this is a joke, it is very well executed.
It's not a joke, BGP servers used to authenticate each other with this in the late 90s. This was also before NAT was really a thing.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#77Earlier quoted context omitted.
If this is a joke, it is very well executed.
It's not a joke, BGP servers used to authenticate each other with this in the late 90s. This was also before NAT was really a thing.
a very small percentage of ISPs at some major IX points still want MD5 auth on BGP sessions across the fabric. Usually a moot point these days since the IX operator should have solid, reliable documentation of exactly what switch port and fiber patch panel assignment goes to which cage/suite/cabinet and ISP.
Or in the case of a PNI between two ISPs over their own cross connect, you absolutely want to have a mutual level of trust and cooperation between the BGP peers on both sides of the session.
And then other more modern methods of verifying that the IP blocks you're seeing from some other AS are legit, like verifying their RPKI signatures, IRR entries, etc.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#78That’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.
Except that if they know you are using this technique (e.g. from snooping traffic) then it is straightforward to bypass, either by tailgating onto a recent connection attempt (if they can snoop) or just brute forcing it (they can test the whole key space in seconds).
There must be better ways to leverage long term shared secrets, recent authentication success, etc. I'd like to see something like Signal's ratchet mechanism.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#79Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#80Looks like fun. :) I do have nftables set up so that connection to normal ssh port blackholes the access to the real ssh port for that source IP address for some time.
Not perfect, but good enough to deter people who'd first naively try to ssh to my server and then try to nmap it to find out if I have ssh running on some other port. :)
900 IP addresses blackholed just over a 1 day period. "security" scanning is incessant.