If frequency hopping IPv6 becomes popular, I wonder how long until we start having IPv6 exhaustion problems?
Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
141–150 of 200 posts
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#142Earlier quoted context omitted.
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…
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…
No, "why use MD5" is because MD5 is the only one supported by kernels. And it has to be supported by kernels in order to allow any realistic use of a BGP daemon.
I thought this should be clear from the fact that it protects against RST packets. Nothing on an application layer can do that.
I wish I could edit that comment because while I expected people to go "oh, I didn't know TCP had that!", multiple commenters seem to have not read past "MD5" and assumed that this is pure application-level.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#143If frequency hopping IPv6 becomes popular, I wonder how long until we start having IPv6 exhaustion problems?
Never.
> The [ipv6] address space therefore has 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#144There 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…
Your point seems valid and reasonable, however looking a couple years in the past there was a situation where you would be screwed with that setup: https://www.debian.org/security/2008/dsa-1571
That was the infamous security flaw where SSH keys generated on debian/ubuntu were always out of a set of 32768 keys due to lack of entropy in key generation. So if your SSH setup is compromised like this, the approach in the article would have provided an additional layer of security.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#145Earlier 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…
OK, I measured a dozen machines, and I found a very mixed picture using 'openssl speed'. - Lots of modern x86 machines with SHA-NI that were typically 50-300% faster than MD5 - Older Intel machines, where SHA1 was generally slightly faster, with one or two exceptions where the reverse was true. - ARM machines with good SIMD/NEON where the NEON implementation of SHA1 was 30-40% faster than MD5. - Embedded ARM machines…
It's not about speed. It's about kernel support. And RFC2385 has kernel support and TCP-AO does not. See other comments.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#146Earlier quoted context omitted.
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 f…
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…
> when every library already ships more modern alternatives.
Kernel needs support. This cannot be done in user space.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#147Earlier quoted context omitted.
The simple fact that ssh is over IPv6 already leaves out 99% of potential hackers aka bots.
I have some "cloud" VMs which have been around several years, they're attacked constantly, I haven't seen a single incoming IPv6 source to date. I wonder if there's a "missed opportunity" for hackers there given presumably how many forget to configure their IPv6 firewall.
The search space is too enormous. Which is why you (somebody with a SSH server) should do IPv6 and then forget this other weirdness. [You should do publickey and so on, but I mean the Tosh stuff is "weirdness"]
Suppose you can write code that can try to connect to the SSH server on one million IP addresses per hour, if they respond you attempt an attack. You can try all of the servers in the entire IPv4 Internet in a few months even with a pretty naive algorithm.
But if you do this with IPv6 you won't ever finish trying addresses and indeed almost certainly won't find even one server (let alone successfully attack one) in your lifetime.
So immediately you need a more expensive attack method. Maybe you buy a supply of "passive DNS" (name -> address answers stripped of information about who asked, many big DNS providers sell this) which is not cheap and not well suited to this problem but it gets you somewhere. You pull out IPv6 addresses and try to SSH connect to them from your supplied list. This could work, but now you need to hope that your potential victims revealed themselves to you, all the juicy SSH servers in the world are invisible otherwise.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#148Earlier quoted context omitted.
Is there any reference material about the culture of "if it's in the intranet it's safe"? I have had this problem with some enterprise clients, but I would like to have reference material that I can use as an authoritive source. An obvious thing that springs to mind is that the default campus network design that is in all the standard Cisco designs let to basically everything being vulnerable when the last exchange e…
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 holes into the old system the whole thing becomes way more insecure than they're actually aware of.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#149Stop 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.
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.