14 ms·

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

217 points by Avamander 5y ago

waihtis 5y ago
Really cool idea. If someone is interested further in the general concept it is called ”moving target defense.”
- ryanlol 5y ago
  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.
  - waihtis 5y ago
    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
    - ranieuwe 5y ago
      This solution switches the listening address (IPv6 address), not the port.
      - waihtis 5y ago
        Indeed you are correct.. Fruits of multitasking..
    - gruez 5y ago
      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 https://nmap.org/book/synscan.html
      - waihtis 5y ago
        Both scenarios assume a pretty heavy compromise already in place before the ssh control starts crumbling
      - throwaway2048 5y ago
        there is no "easily bypassing this scheme with a port/address scan" when it comes to ipv6 /64 ranges. If you could scan 1 million IP addresses a second on a /64 (which is absurd), it would take 600K years to scan a full /64.
        toast0 5y ago
        1 million IPs per second is doable with gigE if we're just sending a syn to port 22. I'm going to go out on a limb and assume your server has at least gigE.
        throwaway2048 5y ago
        However I don't think my server has 600000 years of runtime, or a sane firewall config is gonna allow 1 million connections a second.
        waihtis 5y ago
        Not sure why youre getting downvoted, I think an nmap based attack against this kind of rotating setup sounds borderline ridiculous
        ryanlol 5y ago
        This does not use a full /64. > If you could scan 1 million IP addresses a second on a /64 (which is absurd) Not at all, I regularly scan the internet at well over 20Mpps.
- bcoates 5y ago
  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 5y ago
    [deleted]
thecodemonkey 5y ago
That’s a super cool concept, but doesn’t this fall a bit under “security by obscurity”?
- yonixw 5y ago
  I think the time aspect makes it OK, otherwise TOTP itself should be abandoned due to the same principle. (SSH still has password)
- benjohnson 5y ago
  It's another layer of security. There have been exploits of OpenSSH in past so this may be prudent.
  - zbuf 5y ago
    Trouble with extra layers, there's a point where it results in complexity. Which, in my experience, is more likely to be the root cause of a security problem. I'm not saying this little demo is a disaster or anything. But for example, perhaps it requires an awareness of this scheme in an external firewall's rules, and maybe another machine pops up in the rather large IPv6 range that's now available. At its extreme, these sorts of approaches can bring a lack of clarity which layer is providing the actual security.
  - lucb1e 5y ago
    I actually looked into this a few months ago and if memory serves, the last default setup authentication bypass was in something like 2003. Since then, I think the worst thing has been user enumeration. And 2003 was a very different world in terms of how much we cared about hardening, so ssh being reliable throughout all that time is really quite something.
- dec0dedab0de 5y ago
  Yes, but that's only bad if it's your only security.
  - anjbe 5y ago
cliffy 5y ago
Anyone done TOTP port-knocking to open an SSH listen port with just the originator white-listed for a short window?
- Zenst 5y ago
  I had a port-knocking ssh OpenBSD setup late 90's, did move the port about though, just white listed opened. Used SKEY for port sequence, was easy to run even on a Nokia in Java() in that era. [EDIT ADD]>Actually was some Symbian and then Java implementation of the skey. Had Psion Series 5 used initially.
notorandit 5y ago
Super koel!
andi999 5y ago
Somehow my windows computer doesn't want to fetch the correct time. Would probably be a nightmare.
- atatatat 5y ago
  Win10?
  - andi999 5y ago
    Yup
  - pmlnr 5y ago
    systemd-timesyncd is also a lovely possibility of forking it up.
jreese 5y ago
And all you have to do is trust that your client and server will always have synchronized clocks...
- alwaysjoe 5y ago
  ... like you need to when using TOTP for anything
  - nfoz 5y ago
    Maybe I'm irrational, but it's one of the things that makes me real hesitant about where I deploy TOTP. Sometimes my cellphones randomly have a wildly wrong time -- a misbehaving (or malicious) cell-tower perhaps? And sometimes my computer gets the wrong time too -- e.g. booting between Windows and Linux screwing up the system timezone setting, or ntp failing to start properly, or when I busted up my CMOS. And I have to wonder, how secure is ntp from someone just spamming a system with the wrong times which can block me out? I'd almost rather a combined thing where it's HOTP but it also rotates once per day like at midnight? Does anything do that, or does it even make sense? Is there a reasonable alternative -- challenge-response maybe?
    - Kwpolska 5y ago
      > Sometimes my cellphones randomly have a wildly wrong time -- a misbehaving (or malicious) cell-tower perhaps? If you experience that often, I would probably disable the setting to automatically set time from the network. > booting between Windows and Linux screwing up the system timezone setting That’s easily fixable with one registry change (RealTimeIsUniversal). You can also tell Linux to use the local time, but Linux will be less happy about that than Windows (Linux won’t write to the real-time clock automatically, for example).
    - shaicoleman 5y ago
      The Linux/Windows timezone issue can be fixed with a registry setting [1] If for some reason your time is off (e.g. after 3 failed attempts), it's easily detectable and fixable. Just browse to time.is [2], and your time is off, and set it manually if needed. Because there's an increased dependency on accurate time, bad network time is now quite a rare occurrence in my experience. I haven't seen it happen in the last 3 years. Once you point NTP to a trustworthy service (e.g. time.google.com [3] or time.cloudflare.com [4]), you won't have any issues. The Google time server offers leap smear [5], and the Cloudflare one offers NTS (authenticated NTP). 1. https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows https://wiki.archlinux.org/title/System_time#UTC_in_Microsof... 2. https://time.is/ https://time.is/ 3. https://developers.google.com/time https://developers.google.com/time 4. https://developers.cloudflare.com/time-services/nts/usage https://developers.cloudflare.com/time-services/nts/usage 5. https://developers.google.com/time/smear https://developers.google.com/time/smear
xbar 5y ago
Hm. Am I ready to build toshnet, a cloud of systems running tosh and a toshepherd, the masternode that stores the totp to find and manage them all? Mayhaps.
wombatpm 5y ago
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 bad time. Fun times
- saltedonion 5y ago
  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.
  - dmos62 5y ago
    My most memorable bug (because of how long debugging took) was inconsistent use of local and UTC timezones. Learned to localize timedates as late as possible (or preferably never) and delocalize as early as possible.
    - znpy 5y ago
      as if it is a rite of passage to become an adult engineer, i'm now facing timezone issues at work. no real problems yet, but the utc vs local timezone has to be handled. Could you please share what did you read on this topic? Thank you!
      - dmos62 5y ago
        I don't think I read anything specific on the topic. I'd simply suggest only using local time in the views. Hopefully that's possible in your use case. Be defensive in your design.
  - treeman79 5y ago
    This is why mission critical systems like Boeing airliners require a reboot. At some point it’s just a lot more practical and safer.
emerged 5y ago
This makes me wonder if you could take this further and make the connection protocol dance across a variety of ports as part of the initial handshake.
- high_priest 5y ago
  Isn't this idea port knocking in essence?
  - emerged 5y ago
    Oh cool, I hadn’t even heard of that.
ericyan 5y ago
This reminds of port knocking. Could be useful if you are really annoyed by those script kiddos, but in essence this is security by obscurity.
- minkzilla 5y ago
  I don't think port knocking is security by obscurity. It is another layer of secret that must be known (or guessed) to gain access.
johnklos 5y ago
Many of us have done something similar, so it's good to see something that's better than a few shell scrips. OTOH, it's written in Rust, which is a bit heavy for something so simple.
thomashabets2 5y ago
Stop it with this cloak and dagger BS. Just set a shared secret on it: https://github.com/google/tcpauth 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.
- lucb1e 5y ago
  > Yes, MD5 is safe for this use Sure, it just begs the question: why in the world would you still try to find nails for the hammer called MD5 when (according to Wikipedia) cryptographers recommended upgrading to SHA-1 in 1996 already? This project's first commit was well, well beyond the deprecation of MD5. It's a bit safer than but also not entirely unlike putting a Windows 7 on the internet just because there are no known exploits in an up-to-date 7 system currently.
  - dogma1138 5y ago
    Cryptographers usually recommend switching to function X for usecase Y. Despite SHA1 today and MD5 for even longer being “insecure” for some use cases there are plenty of usecases for which they are still secure and will remain so. The reason for a wide deprecation is that most people can’t evaluate a hash function or an encryption algorithm in context well so it’s easier to say simply don’t use X. RSA is also crap for many things and it’s slowly but surely being deprecated but it doesn’t mean it’s completely broken for every usecase. Just to be clear I’m not stating that MD5 is necessarily safe for the usecase the GP states it is.
    - lucb1e 5y ago
      Okay but that doesn't explain why it makes sense to still pick an algorithm that more and more holes are being found in when every library already ships more modern alternatives. It would be better to remove the old MD5 code so we can't accidentally have someone use it for use-cases for which it isn't secure, but if people are pedantic about "but for this case I can still use it! Let me just do that!" that will just never happen and we're stuck with MD5 indefinitely.
content_sesh 5y ago
Reminds me of frequency hopping. https://en.wikipedia.org/wiki/Frequency-hopping_spread_spectrum https://en.wikipedia.org/wiki/Frequency-hopping_spread_spect... Interesting side-note, one of the people who re-invented this technique was actress Hedy Lamarr who was quite an accomplished inventor
- lucb1e 5y ago
  One difference is that, as Bluetooth demonstrates, frequency hopping can be extremely fast at basically no cost. If you have a broad enough spectrum that the attacker needs to cover, that actually makes it harder to eavesdrop by adding a real cost (either a better listener or more listening devices). TOTP, on the other hand, typically allows for many seconds of leeway between the two systems, since there is no direct radio communication between the two systems that they can use to synchronize clocks (in the sense of a clock signal rather than actual timekeeping devices).
tekacs 5y ago
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.
- electric_mayhem 5y ago
  Port knocking sucks (subject to replay attacks). Look at Single Packet Authentication. Fwknop is a solid implementation.
walrus01 5y ago
There 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.
- johnklos 5y ago
  Avoiding something like this because the possibility exists that someone will do something else wrong is just silly. Also, the amount of CPU taken by brute force ssh is not zero. There are plenty of good reasons for this. Even if this by itself isn't the best implementation, it's an example of how to make things much, much harder on attackers.
  - walrus01 5y ago
    The amount of CPU taken by brute force SSH on any modern system is negligible - unless we're talking about traffic levels that would qualify as a DDoS. Maybe 0.02 points on a standard unix load scale. In any case you should have something like fail2ban or its equivalent that blackholes traffic from repeated failed attempts to authenticate, not just to your public facing ssh daemon, but lots of other things. The default debian fail2ban daemon configurations, easily toggled on or off to watch various log files, are quite sensible.
    - 5y ago
timf 5y ago
It 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.
- walrus01 5y ago
  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' fully automated ssh username/password attempts that are out there, trying to gain access via well known factory default credentials.
  - timf 5y ago
    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.
    - walrus01 5y ago
ffk 5y ago
Why not just implement Single Packet Authorization (SPA)? The port only opens to that specific source on a recent cryptographically signed request with a timestamp. https://www.linuxjournal.com/article/9621 https://www.linuxjournal.com/article/9621
jftuga 5y ago
I have taken a different approach to remote access in limited scenarios: gofwd: A cross-platform TCP port forwarder with Duo 2FA and Geo-IP integration. Its use case is to help protect services when using a VPN is not possible. Before a connection is forwarded, the remote IP address is geographically checked against city, region (state), and/or country. Distance (in miles) can also be used. If this condition is satisfied, a Duo 2FA request can then be sent to a mobile device. The connection is only forwarded after Duo has verified the user. https://github.com/jftuga/gofwd https://github.com/jftuga/gofwd
electric_mayhem 5y ago
I invented this in November 2019. Regrettably the write up and my PoC implementation are owned by my employer. :-/ Good on you for coming up with it independently. I’m a little jealous, but happy the idea is out in the world.
jchook 5y ago
Would 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)?
- AlexCoventry 5y ago
  If that were useful, the underlying HMAC would be broken.
- lucb1e 5y ago
  To elaborate a bit on what AlexCoventry already said: No. The mechanism underpinning TOTP should guarantee that the internal state does not leak from any outputs produced. That is, of course, unless some security flaw is found, but that seems unlikely to ever happen at this point if you use a regular SHA-2-based TOTP. It basically does HMAC_SHA256(secret, time) where the time is known (also to the attacker) but the secret is shared between the two authenticating systems. If you could derive secret from time+output, the mechanism would serve a much more limited purpose. Part of the purpose of TOTP is that an attacker that observed a (number of) login(s) can't predict any future or past tokens for their own use.
megous 5y ago
Looks 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.
Snawoot 5y ago
I prefer single packet auth with pyknock [1]. SSH config from client side looks like this: Host vm vm-0 vm-0.com User user HostName vm-0.com ProxyCommand sh -c "pyknock-client -s 0.0.0.0 -S \"\$(myip)\" open %h "$(pass my/pyknock/%h)" && sleep 1 && exec nc -4 %h %p" Port 1792 Where `myip` [2] is an small utility which reliably detects my external IP address. [1] https://github.com/Snawoot/pyknock/ https://github.com/Snawoot/pyknock/ [2] https://github.com/Snawoot/myip https://github.com/Snawoot/myip
staticassertion 5y ago
If you're really looking for a second factor for SSH, why not just use a standard 2FA approach, like a yubikey? Or even just TOTP with PAM? It seems way more effective and way less complex.
- staticassertion 5y ago
  Thinking a bit about it, I suppose some advantages would be that there's less exposure by default. It's also going to be easy to audit for port 22 being hit, which an attacker might try. I could see some benefits.
exabrial 5y ago
I've been putting things behind wireguard. It seems to scale nicely and is more resilient against attack by the nature of the protocol.
1ncorrect 5y ago
I played with a similar concept years ago for more general secure transmission where each endpoint would mux traffic to/from multiple addresses from their respective /64 as an added layer of obfuscation. It included optional dummy traffic and intentionally out of sequence transmissions to complicate inspection. It makes more sense when used broadly by the majority of traffic across a link, by multiple clients, but it could be a useful application for IPv6 in environments an intermediate network is untrustworthy.
tambourine_man 5y ago
Same thing with ports, for those stuck on IPv4 https://blog.benjojo.co.uk/post/ssh-port-fluxing-with-totp https://blog.benjojo.co.uk/post/ssh-port-fluxing-with-totp
airhead969 5y ago
Why bother? Why not just use SPA secure port knocking with GPG users and expiring tickets that just hides the port completely using firewall rules unless authorized? fwknop is just one example, and it works for any and all services. Also, there are these internal network creation systems called VPNs. Sensitive ports should be guarded behind VPNs on private networks. And, the VPN port itself should be guarded with SPA port knocking. Stop putting ssh on everything and on public IPs on the actual public internet. Don't do this. Do you know how many weeks were spent cleaning-up after idiots who did this with desktops contracting W32/Blaster? One "secured" Oracle database box on a public IP got an unknown trojan rootkit Mark Russinovich was like: what is this voodoo that they do? The "only" solution, since it "couldn't ever be taken down," was to block everything it didn't explicitly need to function and general outbound internet access. Lack of security, idempotent automation of configuration management, and restoration caused these issues. It languished on for years with what effectively was an "endogenous retrovirus" that "couldn't" be removed.
- londons_explore 5y ago
  It isn't really secure... Because an attacker on the network can see which port you're about to connect to, and which IP you're connecting from, and connect to the target milliseconds before you do. I prefer to keep the word 'secure' for things that provide at least man-in-the-middle protection, which this approach doesn't.
  - airhead969 5y ago
    Single Packet Authorization doesn't claim to do anything about encryption, authentication, integrity, auditing, or anything else. Leave ambiguous terminology hair-splitting at the door and get to specifics. It's securing the keyhole of the padlock. No sense moving the padlock around when it can be closed to begin-with, and opened with a special knock that is extremely complicated: time, service, and identifies which user. Port knocking on top of VPN, SSL, SSH, Wireguard, or whatever. You don't do this with telnet because common sense. Duh!
efitz 5y ago
If frequency hopping IPv6 becomes popular, I wonder how long until we start having IPv6 exhaustion problems?
- heinrichhartman 5y ago
  Never. > The [ipv6] address space therefore has 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses https://en.wikipedia.org/wiki/IPv6 https://en.wikipedia.org/wiki/IPv6
  - efitz 5y ago
    Globally yes. Each network has far fewer.
  - exikyut 5y ago
    If for some crazy reason you wanted to give each byte of memory and storage in a supercomputer its own IPv6 address, you'd be able to scale up to 300 septillion (301,936,594,947,653,725,323,264) nodes, each with 1 terabyte of RAM and 1 petabyte of storage, before IPv6 ran out of individual addresses. That's not even counting the 65535 ports you could then use.
    - efitz 5y ago
      It’s not about how many devices you have. It’s about how many ports you have listening on each device and how frequently they hop addresses.
unop 5y ago
Nice! Surely if IPv6, you're using DNS, no? And not typing out the full changing IPv6 addresses? Even in your homelab? Making this concept a bit moot at best - awkward to manage if anything.
absoluteretard 5y ago
It's a good idea. Personally I prefer to use a SSH key.
michaelcampbell 5y ago
I have a machine exposed to the net on an "obscure" port, with fail2ban running on it. In ... 5-8 years, I haven't had a single hit other than me mistyping a password. I understand the issues around doing this, but I'm actually shocked at how little (zero) incursion attempts it gets. I should also note that since this is a personal machine, I also have entire countries blocked by CIDRs. I also do this for my wife's company's retail presence, and blocking the big 4 (China, Russia, Iran, NK) at a CIDR level stopped something like 98% of the brute force ssh attempts (the vast, vast majority of those from China). I know it's not foolproof, and I may get some false positive blocks, but she doesn't have a business that needs to allow people from those countries.

217 points by Avamander 5y ago

waihtis 5y ago

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

ryanlol 5y ago
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.
- waihtis 5y ago
  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
  - ranieuwe 5y ago
    This solution switches the listening address (IPv6 address), not the port.
    - waihtis 5y ago
      Indeed you are correct.. Fruits of multitasking..
  - gruez 5y ago
    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 https://nmap.org/book/synscan.html
    - waihtis 5y ago
      Both scenarios assume a pretty heavy compromise already in place before the ssh control starts crumbling
    - throwaway2048 5y ago
      there is no "easily bypassing this scheme with a port/address scan" when it comes to ipv6 /64 ranges. If you could scan 1 million IP addresses a second on a /64 (which is absurd), it would take 600K years to scan a full /64.
      - toast0 5y ago
        1 million IPs per second is doable with gigE if we're just sending a syn to port 22. I'm going to go out on a limb and assume your server has at least gigE.
        throwaway2048 5y ago
        However I don't think my server has 600000 years of runtime, or a sane firewall config is gonna allow 1 million connections a second.
        waihtis 5y ago
        Not sure why youre getting downvoted, I think an nmap based attack against this kind of rotating setup sounds borderline ridiculous
      - ryanlol 5y ago
        This does not use a full /64. > If you could scan 1 million IP addresses a second on a /64 (which is absurd) Not at all, I regularly scan the internet at well over 20Mpps.
bcoates 5y ago
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 5y ago
  [deleted]

thecodemonkey 5y ago

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

yonixw 5y ago
I think the time aspect makes it OK, otherwise TOTP itself should be abandoned due to the same principle. (SSH still has password)
benjohnson 5y ago
It's another layer of security. There have been exploits of OpenSSH in past so this may be prudent.
- zbuf 5y ago
  Trouble with extra layers, there's a point where it results in complexity. Which, in my experience, is more likely to be the root cause of a security problem. I'm not saying this little demo is a disaster or anything. But for example, perhaps it requires an awareness of this scheme in an external firewall's rules, and maybe another machine pops up in the rather large IPv6 range that's now available. At its extreme, these sorts of approaches can bring a lack of clarity which layer is providing the actual security.
- lucb1e 5y ago
  I actually looked into this a few months ago and if memory serves, the last default setup authentication bypass was in something like 2003. Since then, I think the worst thing has been user enumeration. And 2003 was a very different world in terms of how much we cared about hardening, so ssh being reliable throughout all that time is really quite something.
dec0dedab0de 5y ago
Yes, but that's only bad if it's your only security.
- anjbe 5y ago

cliffy 5y ago

Anyone done TOTP port-knocking to open an SSH listen port with just the originator white-listed for a short window?

Zenst 5y ago
I had a port-knocking ssh OpenBSD setup late 90's, did move the port about though, just white listed opened. Used SKEY for port sequence, was easy to run even on a Nokia in Java() in that era. [EDIT ADD]>Actually was some Symbian and then Java implementation of the skey. Had Psion Series 5 used initially.

notorandit 5y ago

Super koel!

andi999 5y ago

Somehow my windows computer doesn't want to fetch the correct time. Would probably be a nightmare.

atatatat 5y ago
Win10?
- andi999 5y ago
  Yup
- pmlnr 5y ago
  systemd-timesyncd is also a lovely possibility of forking it up.

jreese 5y ago

And all you have to do is trust that your client and server will always have synchronized clocks...

alwaysjoe 5y ago
... like you need to when using TOTP for anything
- nfoz 5y ago
  Maybe I'm irrational, but it's one of the things that makes me real hesitant about where I deploy TOTP. Sometimes my cellphones randomly have a wildly wrong time -- a misbehaving (or malicious) cell-tower perhaps? And sometimes my computer gets the wrong time too -- e.g. booting between Windows and Linux screwing up the system timezone setting, or ntp failing to start properly, or when I busted up my CMOS. And I have to wonder, how secure is ntp from someone just spamming a system with the wrong times which can block me out? I'd almost rather a combined thing where it's HOTP but it also rotates once per day like at midnight? Does anything do that, or does it even make sense? Is there a reasonable alternative -- challenge-response maybe?
  - Kwpolska 5y ago
    > Sometimes my cellphones randomly have a wildly wrong time -- a misbehaving (or malicious) cell-tower perhaps? If you experience that often, I would probably disable the setting to automatically set time from the network. > booting between Windows and Linux screwing up the system timezone setting That’s easily fixable with one registry change (RealTimeIsUniversal). You can also tell Linux to use the local time, but Linux will be less happy about that than Windows (Linux won’t write to the real-time clock automatically, for example).
  - shaicoleman 5y ago
    The Linux/Windows timezone issue can be fixed with a registry setting [1] If for some reason your time is off (e.g. after 3 failed attempts), it's easily detectable and fixable. Just browse to time.is [2], and your time is off, and set it manually if needed. Because there's an increased dependency on accurate time, bad network time is now quite a rare occurrence in my experience. I haven't seen it happen in the last 3 years. Once you point NTP to a trustworthy service (e.g. time.google.com [3] or time.cloudflare.com [4]), you won't have any issues. The Google time server offers leap smear [5], and the Cloudflare one offers NTS (authenticated NTP). 1. https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows https://wiki.archlinux.org/title/System_time#UTC_in_Microsof... 2. https://time.is/ https://time.is/ 3. https://developers.google.com/time https://developers.google.com/time 4. https://developers.cloudflare.com/time-services/nts/usage https://developers.cloudflare.com/time-services/nts/usage 5. https://developers.google.com/time/smear https://developers.google.com/time/smear

xbar 5y ago

Hm. Am I ready to build toshnet, a cloud of systems running tosh and a toshepherd, the masternode that stores the totp to find and manage them all? Mayhaps.

wombatpm 5y ago

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 bad time. Fun times

saltedonion 5y ago
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.
- dmos62 5y ago
  My most memorable bug (because of how long debugging took) was inconsistent use of local and UTC timezones. Learned to localize timedates as late as possible (or preferably never) and delocalize as early as possible.
  - znpy 5y ago
    as if it is a rite of passage to become an adult engineer, i'm now facing timezone issues at work. no real problems yet, but the utc vs local timezone has to be handled. Could you please share what did you read on this topic? Thank you!
    - dmos62 5y ago
      I don't think I read anything specific on the topic. I'd simply suggest only using local time in the views. Hopefully that's possible in your use case. Be defensive in your design.
- treeman79 5y ago
  This is why mission critical systems like Boeing airliners require a reboot. At some point it’s just a lot more practical and safer.

emerged 5y ago

This makes me wonder if you could take this further and make the connection protocol dance across a variety of ports as part of the initial handshake.

high_priest 5y ago
Isn't this idea port knocking in essence?
- emerged 5y ago
  Oh cool, I hadn’t even heard of that.

ericyan 5y ago

This reminds of port knocking. Could be useful if you are really annoyed by those script kiddos, but in essence this is security by obscurity.

minkzilla 5y ago
I don't think port knocking is security by obscurity. It is another layer of secret that must be known (or guessed) to gain access.

johnklos 5y ago

Many of us have done something similar, so it's good to see something that's better than a few shell scrips. OTOH, it's written in Rust, which is a bit heavy for something so simple.

thomashabets2 5y ago

Stop it with this cloak and dagger BS. Just set a shared secret on it: https://github.com/google/tcpauth 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.

lucb1e 5y ago
> Yes, MD5 is safe for this use Sure, it just begs the question: why in the world would you still try to find nails for the hammer called MD5 when (according to Wikipedia) cryptographers recommended upgrading to SHA-1 in 1996 already? This project's first commit was well, well beyond the deprecation of MD5. It's a bit safer than but also not entirely unlike putting a Windows 7 on the internet just because there are no known exploits in an up-to-date 7 system currently.
- dogma1138 5y ago
  Cryptographers usually recommend switching to function X for usecase Y. Despite SHA1 today and MD5 for even longer being “insecure” for some use cases there are plenty of usecases for which they are still secure and will remain so. The reason for a wide deprecation is that most people can’t evaluate a hash function or an encryption algorithm in context well so it’s easier to say simply don’t use X. RSA is also crap for many things and it’s slowly but surely being deprecated but it doesn’t mean it’s completely broken for every usecase. Just to be clear I’m not stating that MD5 is necessarily safe for the usecase the GP states it is.
  - lucb1e 5y ago
    Okay but that doesn't explain why it makes sense to still pick an algorithm that more and more holes are being found in when every library already ships more modern alternatives. It would be better to remove the old MD5 code so we can't accidentally have someone use it for use-cases for which it isn't secure, but if people are pedantic about "but for this case I can still use it! Let me just do that!" that will just never happen and we're stuck with MD5 indefinitely.

content_sesh 5y ago

Reminds me of frequency hopping. https://en.wikipedia.org/wiki/Frequency-hopping_spread_spectrum https://en.wikipedia.org/wiki/Frequency-hopping_spread_spect... Interesting side-note, one of the people who re-invented this technique was actress Hedy Lamarr who was quite an accomplished inventor

lucb1e 5y ago
One difference is that, as Bluetooth demonstrates, frequency hopping can be extremely fast at basically no cost. If you have a broad enough spectrum that the attacker needs to cover, that actually makes it harder to eavesdrop by adding a real cost (either a better listener or more listening devices). TOTP, on the other hand, typically allows for many seconds of leeway between the two systems, since there is no direct radio communication between the two systems that they can use to synchronize clocks (in the sense of a clock signal rather than actual timekeeping devices).

tekacs 5y ago

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.

electric_mayhem 5y ago
Port knocking sucks (subject to replay attacks). Look at Single Packet Authentication. Fwknop is a solid implementation.

walrus01 5y ago

There 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.

johnklos 5y ago
Avoiding something like this because the possibility exists that someone will do something else wrong is just silly. Also, the amount of CPU taken by brute force ssh is not zero. There are plenty of good reasons for this. Even if this by itself isn't the best implementation, it's an example of how to make things much, much harder on attackers.
- walrus01 5y ago
  The amount of CPU taken by brute force SSH on any modern system is negligible - unless we're talking about traffic levels that would qualify as a DDoS. Maybe 0.02 points on a standard unix load scale. In any case you should have something like fail2ban or its equivalent that blackholes traffic from repeated failed attempts to authenticate, not just to your public facing ssh daemon, but lots of other things. The default debian fail2ban daemon configurations, easily toggled on or off to watch various log files, are quite sensible.
  - 5y ago

timf 5y ago

It 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.

walrus01 5y ago
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' fully automated ssh username/password attempts that are out there, trying to gain access via well known factory default credentials.
- timf 5y ago
  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.
  - walrus01 5y ago

ffk 5y ago

Why not just implement Single Packet Authorization (SPA)? The port only opens to that specific source on a recent cryptographically signed request with a timestamp. https://www.linuxjournal.com/article/9621 https://www.linuxjournal.com/article/9621

jftuga 5y ago

I have taken a different approach to remote access in limited scenarios: gofwd: A cross-platform TCP port forwarder with Duo 2FA and Geo-IP integration. Its use case is to help protect services when using a VPN is not possible. Before a connection is forwarded, the remote IP address is geographically checked against city, region (state), and/or country. Distance (in miles) can also be used. If this condition is satisfied, a Duo 2FA request can then be sent to a mobile device. The connection is only forwarded after Duo has verified the user. https://github.com/jftuga/gofwd https://github.com/jftuga/gofwd

electric_mayhem 5y ago

I invented this in November 2019. Regrettably the write up and my PoC implementation are owned by my employer. :-/ Good on you for coming up with it independently. I’m a little jealous, but happy the idea is out in the world.

jchook 5y ago

Would 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)?

AlexCoventry 5y ago
If that were useful, the underlying HMAC would be broken.
lucb1e 5y ago
To elaborate a bit on what AlexCoventry already said: No. The mechanism underpinning TOTP should guarantee that the internal state does not leak from any outputs produced. That is, of course, unless some security flaw is found, but that seems unlikely to ever happen at this point if you use a regular SHA-2-based TOTP. It basically does HMAC_SHA256(secret, time) where the time is known (also to the attacker) but the secret is shared between the two authenticating systems. If you could derive secret from time+output, the mechanism would serve a much more limited purpose. Part of the purpose of TOTP is that an attacker that observed a (number of) login(s) can't predict any future or past tokens for their own use.

megous 5y ago

Looks 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.

Snawoot 5y ago

I prefer single packet auth with pyknock [1]. SSH config from client side looks like this: Host vm vm-0 vm-0.com User user HostName vm-0.com ProxyCommand sh -c "pyknock-client -s 0.0.0.0 -S \"\$(myip)\" open %h "$(pass my/pyknock/%h)" && sleep 1 && exec nc -4 %h %p" Port 1792 Where `myip` [2] is an small utility which reliably detects my external IP address. [1] https://github.com/Snawoot/pyknock/ https://github.com/Snawoot/pyknock/ [2] https://github.com/Snawoot/myip https://github.com/Snawoot/myip

staticassertion 5y ago

If you're really looking for a second factor for SSH, why not just use a standard 2FA approach, like a yubikey? Or even just TOTP with PAM? It seems way more effective and way less complex.

staticassertion 5y ago
Thinking a bit about it, I suppose some advantages would be that there's less exposure by default. It's also going to be easy to audit for port 22 being hit, which an attacker might try. I could see some benefits.

exabrial 5y ago

I've been putting things behind wireguard. It seems to scale nicely and is more resilient against attack by the nature of the protocol.

1ncorrect 5y ago

I played with a similar concept years ago for more general secure transmission where each endpoint would mux traffic to/from multiple addresses from their respective /64 as an added layer of obfuscation. It included optional dummy traffic and intentionally out of sequence transmissions to complicate inspection. It makes more sense when used broadly by the majority of traffic across a link, by multiple clients, but it could be a useful application for IPv6 in environments an intermediate network is untrustworthy.

tambourine_man 5y ago

Same thing with ports, for those stuck on IPv4 https://blog.benjojo.co.uk/post/ssh-port-fluxing-with-totp https://blog.benjojo.co.uk/post/ssh-port-fluxing-with-totp

airhead969 5y ago

Why bother? Why not just use SPA secure port knocking with GPG users and expiring tickets that just hides the port completely using firewall rules unless authorized? fwknop is just one example, and it works for any and all services. Also, there are these internal network creation systems called VPNs. Sensitive ports should be guarded behind VPNs on private networks. And, the VPN port itself should be guarded with SPA port knocking. Stop putting ssh on everything and on public IPs on the actual public internet. Don't do this. Do you know how many weeks were spent cleaning-up after idiots who did this with desktops contracting W32/Blaster? One "secured" Oracle database box on a public IP got an unknown trojan rootkit Mark Russinovich was like: what is this voodoo that they do? The "only" solution, since it "couldn't ever be taken down," was to block everything it didn't explicitly need to function and general outbound internet access. Lack of security, idempotent automation of configuration management, and restoration caused these issues. It languished on for years with what effectively was an "endogenous retrovirus" that "couldn't" be removed.

londons_explore 5y ago
It isn't really secure... Because an attacker on the network can see which port you're about to connect to, and which IP you're connecting from, and connect to the target milliseconds before you do. I prefer to keep the word 'secure' for things that provide at least man-in-the-middle protection, which this approach doesn't.
- airhead969 5y ago
  Single Packet Authorization doesn't claim to do anything about encryption, authentication, integrity, auditing, or anything else. Leave ambiguous terminology hair-splitting at the door and get to specifics. It's securing the keyhole of the padlock. No sense moving the padlock around when it can be closed to begin-with, and opened with a special knock that is extremely complicated: time, service, and identifies which user. Port knocking on top of VPN, SSL, SSH, Wireguard, or whatever. You don't do this with telnet because common sense. Duh!

efitz 5y ago

If frequency hopping IPv6 becomes popular, I wonder how long until we start having IPv6 exhaustion problems?

heinrichhartman 5y ago
Never. > The [ipv6] address space therefore has 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses https://en.wikipedia.org/wiki/IPv6 https://en.wikipedia.org/wiki/IPv6
- efitz 5y ago
  Globally yes. Each network has far fewer.
- exikyut 5y ago
  If for some crazy reason you wanted to give each byte of memory and storage in a supercomputer its own IPv6 address, you'd be able to scale up to 300 septillion (301,936,594,947,653,725,323,264) nodes, each with 1 terabyte of RAM and 1 petabyte of storage, before IPv6 ran out of individual addresses. That's not even counting the 65535 ports you could then use.
  - efitz 5y ago
    It’s not about how many devices you have. It’s about how many ports you have listening on each device and how frequently they hop addresses.

unop 5y ago

Nice! Surely if IPv6, you're using DNS, no? And not typing out the full changing IPv6 addresses? Even in your homelab? Making this concept a bit moot at best - awkward to manage if anything.

absoluteretard 5y ago

It's a good idea. Personally I prefer to use a SSH key.

michaelcampbell 5y ago

I have a machine exposed to the net on an "obscure" port, with fail2ban running on it. In ... 5-8 years, I haven't had a single hit other than me mistyping a password. I understand the issues around doing this, but I'm actually shocked at how little (zero) incursion attempts it gets. I should also note that since this is a personal machine, I also have entire countries blocked by CIDRs. I also do this for my wife's company's retail presence, and blocking the big 4 (China, Russia, Iran, NK) at a CIDR level stopped something like 98% of the brute force ssh attempts (the vast, vast majority of those from China). I know it's not foolproof, and I may get some false positive blocks, but she doesn't have a business that needs to allow people from those countries.