Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

111–120 of 200 posts

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

#111

Post by spydum »

tptacek wrote: post #108
lamontcg wrote: post #82

Earlier quoted context omitted.

Yeah I suspect that up to date openssh with a config that passes ssh-audit's checks, with a fail2ban config, along with an ed25519 key unlocked by a yubikey will be entirely adequate security for SSH. Then time would be better spent securing VPNs and reducing internal trust. Bit like having a front door that would withstand a C4 blast, but now all your windows are shattered.

Fail2ban is also theater on properly configured SSH servers and has been since it was written.

I've often used fail2ban not as a security control, but a log hygiene solution. I don't need 10000s of failed login attempts in my logs, it's annoying. I have full faith it's not stopping a server compromise, but it absolutely keeps the noise level down.

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

#112

Post by mindcrime »

not_kurt_godel wrote: post #54
ad404b8a372f2b9 wrote: post #8

Earlier quoted context omitted.

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 try…

If you have real security, then you don't need security by obscurity. If you have security by obscurity, you still need real security.

If "real security" was a real thing and anybody knew how to actually do that, things like the Colonial Pipeline ransom-ware attack, etc. wouldn't happen all the time. As people have been saying since David Lightman in 1983 "Hey, I don't believe that any system is totally secure."

That's not to say security by obscurity layered on top can't be useful

I think that most people who would implement this (or similar schemes) realize exactly that, and are practicing "defense in depth". Could it be a "dangerous distraction?" Sure, in principle. But I don't see any particular reason that this would be more so than other elements of a "defense in depth" strategy.

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

#113

Post by walrus01 »

tptacek wrote: post #108
lamontcg wrote: post #82

Earlier quoted context omitted.

Yeah I suspect that up to date openssh with a config that passes ssh-audit's checks, with a fail2ban config, along with an ed25519 key unlocked by a yubikey will be entirely adequate security for SSH. Then time would be better spent securing VPNs and reducing internal trust. Bit like having a front door that would withstand a C4 blast, but now all your windows are shattered.

Fail2ban is also theater on properly configured SSH servers and has been since it was written.

I don't think anyone but the most uninformed would argue that fail2ban is an actual secure measure, it's more of a log file annoyance reducer. Obviously if you leave remote root enabled and the root password is one of a few dozen thousand common words that exist out there in public-domain password data sets, fail2ban isn't going to help much. As with the example of all the random botnet things out there that randomly try a popular list of dozens of common usernames (admin, root, webmaster, etc) with common passwords.

With things other than SSH it can also be effective in the most rudimentary first level filtering out of spam, various things that attempt to relay mail through my server get themselves first banned, and then banned for a longer time after they keep re-trying. Again with primarily the goal of having less cluttered postfix logs.

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

#114

Post by cperciva »

ekarulf wrote: post #73
thomashabets2 wrote: post #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.

Is this just spiped with MD5 instead of HMAC-SHA256? https://www.tarsnap.com/spiped.html

No, spiped also encrypts data.

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

#115

Post by 1ncorrect »

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.

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

#116

Post by behringer »

walrus01 wrote: post #113
tptacek wrote: post #108

Earlier quoted context omitted.

Fail2ban is also theater on properly configured SSH servers and has been since it was written.

I don't think anyone but the most uninformed would argue that fail2ban is an actual secure measure, it's more of a log file annoyance reducer. Obviously if you leave remote root enabled and the root password is one of a few dozen thousand common words that exist out there in public-domain password data sets, fail2ban isn't going to help much. As with the example of all the random botnet things out there that randomly…

Fail2ban is also useful if you do leave something misconfigured. Mistakes happen so having a little redundancy is OK.

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

#117

Post by boring_twenties »

mlyle wrote: post #103
dogma1138 wrote: post #101

Earlier quoted context omitted.

I’m not going to evaluate if MD5 is safe for “tcpauth” even if I was competent enough to do so. If confidentiality isn’t a factor (since any hush function that is fast m enough to brute force isn’t going to be particularly secure) and if integrity cannot be compromised through collisions then the hash function is safe for this usecase. Why use MD5? It’s relatively easy to implement securely m, there are a lot of safe…

CRC32 is used for its error detection properties which exceed those of a cryptographic hash of the same length (and, to boot, it's cheaper, too). There's no reason to choose MD5 over SHA-1. It's less secure and slower and there's plenty of free implementations of SHA-1. Ideally you'd use SHA-256, because of (smaller) security concerns with SHA-1, but it is a small touch slower than MD5.

MD5 is quite a bit faster on my machine.

  % for i in md5 sha1 sha256 sha512; do echo -n "$i: ";  time ${i}sum test.bin > /dev/null ; done 
  md5: ${i}sum test.bin > /dev/null  1.37s user 0.13s system 99% cpu 1.501 total
  sha1: ${i}sum test.bin > /dev/null  1.84s user 0.12s system 99% cpu 1.952 total
  sha256: ${i}sum test.bin > /dev/null  4.43s user 0.16s system 99% cpu 4.593 total
  sha512: ${i}sum test.bin > /dev/null  2.69s user 0.12s system 99% cpu 2.810 total
Surprisingly, SHA256 is much slower than SHA512 here.

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

#118

Post by tptacek »

behringer wrote: post #116
walrus01 wrote: post #113

Earlier quoted context omitted.

I don't think anyone but the most uninformed would argue that fail2ban is an actual secure measure, it's more of a log file annoyance reducer. Obviously if you leave remote root enabled and the root password is one of a few dozen thousand common words that exist out there in public-domain password data sets, fail2ban isn't going to help much. As with the example of all the random botnet things out there that randomly…

Fail2ban is also useful if you do leave something misconfigured. Mistakes happen so having a little redundancy is OK.

Apply your redundancy to whatever is generating and safeguarding your SSH configurations.

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

#119

Post by orev »

TacticalCoder wrote: post #95
wombatpm wrote: post #29

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…

TOTP issues related to bogus clocks are soooooo common that I've got my own public TOTP "secret" (so not really a secret) which I use to verify that my various devices running TOTP authenticators have the correct time (my phone, wife's phone, an airline/airgapped device running TOTP etc.). It's so bad that Google's own authenticator has a "time synch" functionality or something like that in the very TOTP app (and it…

TOTP systems are supposed to implement a sliding window to account for reasonable clock differences, usually within 5 minutes. Devices further off from that really do have a problem, and should not be trusted. I also find it hard to believe that so many devices are so far off, given the ubiquitous access to GPS (atomic clock) signals and NTP on networks. This has been a solved problem for a long time.

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

#120

Post by staticassertion »

staticassertion wrote: post #91

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.

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.
Post reply on HN