Same thing with ports, for those stuck on IPv4
Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
121–130 of 200 posts
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#122Earlier quoted context omitted.
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 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 with bad SIMD/NEON where it was pretty much a tie.
- A few ARM machines-- most notably Broadcom chipsets in the Raspberry Pi, where MD5 wins big a large margin.
- Embedded MIPS 24k, where MD5 won by 33%.
Then I found http://bench.cr.yp.to/results-hash.html , which bears out what I'd measured.
In any case, I don't think "speed" is any reason to select MD5, unless maybe if you're on MIPS 24k.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#123Earlier quoted context omitted.
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.
> 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.)
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#124Why 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.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#125Earlier quoted context omitted.
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.
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.
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.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#126Earlier quoted context omitted.
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.
I had inherited a server (Arch linux) which ran something like fail2ban (can't remember what it's called). It slowed down the machine tremendously, because the iptables lists became very big, and every packet started taking up too much CPU. I had to disable it (switching to whitelisting instead). Did you ever encounter something like this with fail2ban?
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#127Why 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…
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.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#128Earlier quoted context omitted.
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.
My Windows 10 clock goes 2-5x faster when I hibernate and come back
There is a funny bug with Windows Vista in KVM/QEMU where the clock ticks about 1000x faster than it should. You can see the hour hand moving in the clock panel, and animations play at warp speed, and media playback is extremely screwy.
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#129Make 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…
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.
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...
Re: Tosh: Changing your SSH server's listen address every 30 seconds based on TOTP
#130And all you have to do is trust that your client and server will always have synchronized clocks...
From looking at the code, seems like it would be a pretty simple change to make the server accept several addresses, derived from the current time plus or minus a small number of 30-second intervals. That allows you to tolerate a small amount of clock skew, and if your clock is off by more than a minute or two, you should probably fix it anyway.
Just need to SSH in to fix it....