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

181–190 of 200 posts

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

#181

Post by mlyle »

tptacek wrote: post #180
thomashabets2 wrote: post #149

Earlier quoted context omitted.

Not a joke. I'm suspecting you don't understand that this is using a kernel-level feature, so if you think the joke is MD5, then please add rfc5925 to every OS so that I can switch to a better algorithm. You use what actually exists. It's orders of magnitude better than portknocking BS.

Deploying a half-assed encrypted transport in front of a full-assed encrypted transport because you're afraid you might not know how to configure the full-assed encrypted transport is pretty funny, which is why I thought it might be a joke. Port knocking, fail2ban, nonstandard SSH ports, all of that stuff is theater.

There is a benefit from this "half-assed" encrypted transport, though-- someone in the middle who can inject packets can't disrupt your connection.

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

#182

Post by tptacek »

mlyle wrote: post #181
tptacek wrote: post #180

Earlier quoted context omitted.

Deploying a half-assed encrypted transport in front of a full-assed encrypted transport because you're afraid you might not know how to configure the full-assed encrypted transport is pretty funny, which is why I thought it might be a joke. Port knocking, fail2ban, nonstandard SSH ports, all of that stuff is theater.

There is a benefit from this "half-assed" encrypted transport, though-- someone in the middle who can inject packets can't disrupt your connection.

Whatever they did to get into a vantage point where they can predict sequence numbers gives them a bunch of other tools to disrupt connectivity.

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

#183

Post by orev »

nfoz wrote: post #123
orev wrote: post #119

Earlier quoted context omitted.

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.

> TOTP systems are supposed to implement a sliding window to account for reasonable clock differences, usually within 5 minutes. The default is 30 seconds, as per the RFC: https://datatracker.ietf.org/doc/html/rfc6238 (not sure that meaningfully changes what you were saying, but just fyi.)

30 seconds is the default “time step” (4.2), but in talking about the transmission delay window (5.2), which the RFC recommends “at most 1 time step”, but also says that validation should occur for both the previous and next time step window. However in practical implementations, 5 minutes on both sides is typically used.

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

#184

Post by mlyle »

tptacek wrote: post #182
mlyle wrote: post #181

Earlier quoted context omitted.

There is a benefit from this "half-assed" encrypted transport, though-- someone in the middle who can inject packets can't disrupt your connection.

Whatever they did to get into a vantage point where they can predict sequence numbers gives them a bunch of other tools to disrupt connectivity.

Perhaps, perhaps not.

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

#185

Post by lamontcg »

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 the same as having high number of rounds on password hashes to slow down attackers, and it takes about 30 seconds to install+configure. it makes a lot more sense than the title here, but is only useful as security-in-depth and can't replace other good practices. high rounds on a password hash is also equally useless if you use "password123" or something like that.

i've also seen significant reductions in idle cpu by using it and sending offenders to the timeout bin for 24h.

thanks for calling me "most uninformed" though.

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

#186

Post by lucb1e »

Godel_unicode wrote: post #109
lucb1e wrote: post #89

Earlier quoted context omitted.

Except that passwords, private keys, and safe combinations cannot be guessed in 0.1 seconds the way that a port can (65k possible values and a SYN packet really isn't large). There is a line to be drawn between high-entropy secrets and using an unpredictable port number.

Where are people getting the idea that "listening address " means port number? The title of the page literally says IP address...

Ah, misunderstanding on my part. For what it's worth, it doesn't say IP address, just listening address which I just took as whatever place (IP,port tuple) it listens on, and unless one has a huge IP range (uncommon with typical setups) I can see how "people" take that to mean port changing by default if they, like me, don't read carefully enough.

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

#187

Post by dmos62 »

znpy wrote: post #175
dmos62 wrote: post #40

Earlier quoted context omitted.

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.

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!

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.

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

#188

Post by thomashabets2 »

tptacek wrote: post #182
mlyle wrote: post #181

Earlier quoted context omitted.

There is a benefit from this "half-assed" encrypted transport, though-- someone in the middle who can inject packets can't disrupt your connection.

Whatever they did to get into a vantage point where they can predict sequence numbers gives them a bunch of other tools to disrupt connectivity.

Aside from DDoS, no not really. Not if every single accepted packet needs to be signed.

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

#189

Post by thomashabets2 »

tptacek wrote: post #180
thomashabets2 wrote: post #149

Earlier quoted context omitted.

Not a joke. I'm suspecting you don't understand that this is using a kernel-level feature, so if you think the joke is MD5, then please add rfc5925 to every OS so that I can switch to a better algorithm. You use what actually exists. It's orders of magnitude better than portknocking BS.

Deploying a half-assed encrypted transport in front of a full-assed encrypted transport because you're afraid you might not know how to configure the full-assed encrypted transport is pretty funny, which is why I thought it might be a joke. Port knocking, fail2ban, nonstandard SSH ports, all of that stuff is theater.

Well, sorta. TCP MD5 hasn't had preauth exploits. OpenSSH has.

But also, like I said in my blog post (https://blog.habets.se/2019/11/TCP-MD5.html) this isn't just about targeted attacks, but this also hides from things like Shodan, which connects to all your ports and records your headers.

It helps with wide-scale scanning and wide exploitation. Security isn't a yes/no, and getting out these databases without restricting by IP address isn't without actual security value.

E.g. if you do this then next time there's an OpenSSH bug, you won't be in Shodan and other more secret scanning databases to be picked off right away.

Port knocking is just plain overengineered silliness. If plaintext password to unlock another port is what you want, set up a UDP server. "Connecting to random ports" is just fooling yourself about what you're doing.

TCP MD5 least has the benefit that it prevents any kind of shenanigans happening to your connection.

fail2ban, agreed. The value fail2ban adds is keeping your logs more quiet.

nonstandard SSH ports, agreed. Especially after everyone and their dog scans all ports on the whole internet now anyway.

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

#190

Post by walrus01 »

thomashabets2 wrote: post #139
walrus01 wrote: post #77

Earlier quoted context omitted.

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

Citation needed. The ISPs I've worked for run this pretty much everywhere. I mean it's the only auth that exists for BGP, so why would you not want it?

Citation needed: I've maintained direct sessions over the fabric (not via route servers) between my AS and peers' ASes, with over a hundred ISPs, at some of the world's largest IXes. Out of those more than a hundred, maybe 3 used MD5. We also have a lot of PNIs direct with other carriers with POPs in the same building. Sorry I obviously can't provide a copy/paste of the junos config showing all the peers.
Post reply on HN