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

191–200 of 200 posts

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

#191

Post by walrus01 »

lamontcg wrote: post #185
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 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…

I wasn't calling you most uninformed, your statement is totally correct, I was referring to any persons who might argue that fail2ban is purely useless as security theater. What I said was that fail2ban is useful as an annoyance/log clutter reducer, but not something that's an actual security measure which would be suitable to protect a poorly-configured sshd.

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

#192

Post by boring_twenties »

NovemberWhiskey wrote: post #176
boring_twenties wrote: post #117

Earlier quoted context omitted.

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

> Surprisingly, SHA256 is much slower than SHA512 here. SHA512 is expected to be faster than SHA256 on modern 64 bit architectures due to fewer rounds per byte.

Thanks. Shows how much I know! At least I am kind of handy with the shell...

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

#193

Post by tptacek »

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

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

How long ago was the last viable standard-configuration OpenSSH pre-auth vulnerability? Was it within the last decade? If it's the Debian RNG vulnerability --- a platform vulnerability, not an OpenSSH vulnerability --- how much further back do you have to go to find the next one?

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

#194

Post by Godel_unicode »

lucb1e wrote: post #186
Godel_unicode wrote: post #109

Earlier quoted context omitted.

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.

Huge ranges of IPv6 addresses are extremely common, virtually no ISP can be bothered to allocate smaller blocks than a /64. The minimum allocation of addresses recommended is a /32, which is 65k addresses.

You also know they don't mean port numbers because there's no such thing as a 6-digit port number.

From tfa: """Imagine your SSH server only listens on an IPv6 address, and where the last 6 digits are changing every 30 seconds"""

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

#195

Post by mrtesthah »

exikyut wrote: post #157
throwaway2048 wrote: post #129

Earlier quoted context omitted.

A very annoying DNS over HTTPS/TLS circular dependency bug manifests itself if your device doesn't have an RTC, or the battery is dead, or the clock is sufficiently skewed. Clock is fucked, so TLS certs don't verify due to validity times, so DNS is broken, so NTP cant look up domains, so the clock can't be set...

At the end of the day since TLS depends on correct time to trust certificates, I guess the "everything is fine" solution is to fetch the DoH server's TLS cert, inspect the start and end dates, set the system time to the exact middle, then helicopter over NTP a bit to make sure it came up and changed the time to something hopefully correct. On the one hand there's not very much else you can do since you're pointing at…

The best and simplest solution would just be to require an administrator to input the current date manually in that circumstance.

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

#196

Post by thomashabets2 »

tptacek wrote: post #193
thomashabets2 wrote: post #189

Earlier quoted context omitted.

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

How long ago was the last viable standard-configuration OpenSSH pre-auth vulnerability? Was it within the last decade? If it's the Debian RNG vulnerability --- a platform vulnerability, not an OpenSSH vulnerability --- how much further back do you have to go to find the next one?

Sure, it was a while ago. But there are less severe bugs too. Fact remains though that something more complex is more likely to have a bug.

With TCP MD5 you don't even have to consider SYNfloods or SYNcookies. And because only people with the MD5 secret can even connect, it becomes an early tripwire if someone does have the password. Currently if you have an OpenSSH open to the world you should expect your logs to be spamming 24/7, which makes smarter attacks not stick out.

Frankly, given the option I would prefer to not even have port 22 advertise to the world exactly which OpenSSH and OS I use. Not because of security through obscurity, but just to make it slightly harder, and thus harder to get in without tripping any of the tripwires.

Then there's also people who add 6 digit OTP as a second factor. Those are pretty brute-forcable by default, so you can actually do online brute force of a user's password still. Just slower. (OpenSSH has a ratelimit, but I've gotten around TOTP this way). With a system wide good secret this can prevent brute forcing even in the presence of bad user passwords.

But if you've already decided that security is either yes or no, and that OpenSSH is marked "yes secure, and therefore can be open to the world forever, bravely taunting any attacker saying 'this far, no further'", then there's nothing I can say to convince you.

But also not everything on the Internet is (Open)SSH.

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

#197

Post by thomashabets2 »

tptacek wrote: post #193
thomashabets2 wrote: post #189

Earlier quoted context omitted.

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

How long ago was the last viable standard-configuration OpenSSH pre-auth vulnerability? Was it within the last decade? If it's the Debian RNG vulnerability --- a platform vulnerability, not an OpenSSH vulnerability --- how much further back do you have to go to find the next one?

Oh, another aspect to this: OpenSSH may not have a bug, but maybe you need to interface using a PAM module to a radius or LDAP server. Suddenly the trust weakens.

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

#198

Post by fulafel »

rjzzleep wrote: post #148
beermonster wrote: post #136

Earlier quoted context omitted.

90s security was about protecting perimeters and network boundaries. That kind of approach, network segregation/firewalls to keep your data secure, leads to the idea that you are magically protected across impenetrable network boundaries. Which leads people to think insecure protocols are OK on the LAN, or patching policy can be slower etc. These days you would treat the LAN as untrusted and start from there. Assume…

I know all of these. I also don't need a reference to Zero Trust or beyondcorp. What I'm asking for is specifically authority that can be quoted in an enterprise context to make a case for these issues. I would however also like to hear cases against Zero Trust and Beyondcorp. The most obvious I see with the old approach is that oftentimes Engineers in those environments are not able to work and when security punches…

Microsoft and Google for example have published this kind of literature.

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

#199

Post by not_kurt_godel »

mindcrime wrote: post #112
not_kurt_godel wrote: post #54

Earlier quoted context omitted.

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…

"real security" means security that is not dependent on secrecy of implementation to remain secure. In the context of this post, it means configuring key-based access and disabling password-based access. If you do this, then the security-by-obscurity-based technique in the OP is unnecessary and redundant. Could key-based SSH access theoretically be cracked? Maybe (probably not, but let's say maybe for the sake of argument). But if so, a rotating listening address is probably no obstacle to an attacker of that caliber.

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

#200

Post by mindcrime »

not_kurt_godel wrote: post #199
mindcrime wrote: post #112

Earlier quoted context omitted.

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…

"real security" means security that is not dependent on secrecy of implementation to remain secure. In the context of this post, it means configuring key-based access and disabling password-based access. If you do this, then the security-by-obscurity-based technique in the OP is unnecessary and redundant. Could key-based SSH access theoretically be cracked? Maybe (probably not, but let's say maybe for the sake of arg…

Could key-based SSH access theoretically be cracked? Maybe (probably not, but let's say maybe for the sake of argument).

Of course it could. Unless you're really going to posit that there are no bugs in any widely deployed ssh server implementations. Doesn't seem very likely to me.

Anyway... if you're being specifically targeted by a highly advanced adversary, it probably doesn't matter what you do. I tend to assume that most of us, most of the time, are not in that position, and should employ a layered, "defense in depth" strategy. Whether or not this specific technique is something worth deploying or not is an open question to me. My position is simply that we shouldn't just dismiss it out of hand without deeper consideration.

Post reply on HN