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

171–180 of 200 posts

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

#171

Post by xorcist »

sig-reduction wrote: post #164
xorcist wrote: post #163

Earlier quoted context omitted.

> Port-knocking is supposed to be a way to reduce attack surface. No, it's a bet that your port knocking tool has less (or better tested) attack surface than OpenSSH. OpenSSH is pretty thoroughly tested by now, and the pre-auth parts runs with very little privileges. The specific port knocking tool linked to above seems to expose very little, but there's still some logging going on that wouldn't happen otherwise and…

Tx for the insight. Does the extra logging carry a risk over and above dos (which is mitigated by the `-m limit` stuff in the iptables rules)?

Not much of an insight perhaps, just an observation. Risks are notoriously hard to quantify.

But where there's an attack surface there is a risk. There's logging and parsing of logs going on here.

Does that translate to practical risk, in the sense that your system will get owned in this way? Personally I wouldn't consider it very likely. A Linux box won't get popped via a plain open openssh but likely not via this python log parser either. It's still not a bet I would take.

There's so much going on in a network stack that I would look for bugs there before the same in pre-auth openssh but one does not know for certain until after the fact.

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

#172

Post by Aeolun »

hannob wrote: post #160
CydeWeys wrote: post #105

Earlier quoted context omitted.

There's a principle in security called "defense in depth". Your servers shouldn't be SSHable from the public Internet, but even if that's bypassed somehow, there should still be other layers of security. Each layer of protection adds security.

There's also a principle in security that's called simplicity. "Defense in depth" is often quoted when people want to add further complexity to a system. There are cases where adding a security mechanism that adds complexity has a benefit that is so large that it's justified (e.g. adding TLS or ASLR). But it always needs to be balanced, because complexity adds attack surface. The system linked here seems like it's ad…

That’s probably why it is described as a toy.

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

#173

Post by behringer »

tptacek wrote: post #118
behringer wrote: post #116

Earlier quoted context omitted.

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.

What does this even mean? I'm the one who generates the ssh configuration for my computer clubs server...

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

#175

Post by znpy »

dmos62 wrote: post #40
saltedonion wrote: post #36

Earlier 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 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!

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

#176

Post by NovemberWhiskey »

boring_twenties wrote: post #117
mlyle wrote: post #103

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

>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.

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

#177

Post by CydeWeys »

hannob wrote: post #160
CydeWeys wrote: post #105

Earlier quoted context omitted.

There's a principle in security called "defense in depth". Your servers shouldn't be SSHable from the public Internet, but even if that's bypassed somehow, there should still be other layers of security. Each layer of protection adds security.

There's also a principle in security that's called simplicity. "Defense in depth" is often quoted when people want to add further complexity to a system. There are cases where adding a security mechanism that adds complexity has a benefit that is so large that it's justified (e.g. adding TLS or ASLR). But it always needs to be balanced, because complexity adds attack surface. The system linked here seems like it's ad…

Not making your servers SSHable from the public Internet is absolutely worth it though, and has better simplicity than exposing them (which requires setting up firewall/NAT routes).

To be clear, we haven't been talking about the OP port-shuffling scheme for many posts now in this subthread. We're talking about not having your servers be externally SSHable, period.

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

#178

Post by michaelcampbell »

I have a machine exposed to the net on an "obscure" port, with fail2ban running on it.

In ... 5-8 years, I haven't had a single hit other than me mistyping a password. I understand the issues around doing this, but I'm actually shocked at how little (zero) incursion attempts it gets.

I should also note that since this is a personal machine, I also have entire countries blocked by CIDRs. I also do this for my wife's company's retail presence, and blocking the big 4 (China, Russia, Iran, NK) at a CIDR level stopped something like 98% of the brute force ssh attempts (the vast, vast majority of those from China).

I know it's not foolproof, and I may get some false positive blocks, but she doesn't have a business that needs to allow people from those countries.

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

#179

Post by _wldu »

mercora wrote: post #134
tgv wrote: post #126

Earlier quoted context omitted.

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?

at a previous job i cleaned up after such mess. they used to have fail2ban adding thousands of rules without ever deleting them automatically. I replaced it with a pam module that maintained an ipset for addresses with failed login attempts.

ipset is very efficient.

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

#180

Post by tptacek »

thomashabets2 wrote: post #149
tptacek wrote: post #65

Earlier quoted context omitted.

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.

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.

Post reply on HN