Live data from Hacker News

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

github.com

131–140 of 200 posts

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

#131

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

Single Packet Authorization doesn't claim to do anything about encryption, authentication, integrity, auditing, or anything else.

Leave ambiguous terminology hair-splitting at the door and get to specifics.

It's securing the keyhole of the padlock. No sense moving the padlock around when it can be closed to begin-with, and opened with a special knock that is extremely complicated: time, service, and identifies which user.

Port knocking on top of VPN, SSL, SSH, Wireguard, or whatever. You don't do this with telnet because common sense. Duh!

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

#132
post #111

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

While fail2ban might still be a good practice, I've found that simply using a non-standard SSH port is just as effective at keeping the logspam down.

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

#133
post #93

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

You're against this because it gives a false sense of security and might make people relax other measures, but then you suggest going with an intranet, which is widely known to create a culture of "if it's in the intranet it's safe" which is very detrimental to security as well - thought it was curious.

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 exploit hit or the last solarwinds issue occured. But I would like to have some sources so that I can make a better case to senior management.

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

#134
post #126
post #111

Earlier quoted context omitted.

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?

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.

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

#135
post #93

Earlier quoted context omitted.

You're against this because it gives a false sense of security and might make people relax other measures, but then you suggest going with an intranet, which is widely known to create a culture of "if it's in the intranet it's safe" which is very detrimental to security as well - thought it was curious.

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…

The entire concept of zero trust network.

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

#136
post #93

Earlier quoted context omitted.

You're against this because it gives a false sense of security and might make people relax other measures, but then you suggest going with an intranet, which is widely known to create a culture of "if it's in the intranet it's safe" which is very detrimental to security as well - thought it was curious.

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 already compromised. And focus on people, processes, technology, and data. Where is the corporate network boundary these days anyway in the COVID/WFH era? People's homes with all their insecure equipment? Of course you still would have your network segmentation. But as part of defence-in-depth. You just assume it's ineffective or will be circumvented, which it often trivially is: phishing, social engineering etc.

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

#137

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

> And of course keep up to date on openssh patches and security advisories. What about 0-day security breaches? Often fix preparation takes months before been available to end users. All this time your system is vulnerable.

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

#138
post #86

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

> Yes, MD5 is safe for this use Sure, it just begs the question: why in the world would you still try to find nails for the hammer called MD5 when (according to Wikipedia) cryptographers recommended upgrading to SHA-1 in 1996 already? This project's first commit was well, well beyond the deprecation of MD5. It's a bit safer than but also not entirely unlike putting a Windows 7 on the internet just because there are n…

I'm not finding ways to to use MD5. TCP MD5 is supported on Linux and BSDs, and TCP-AO isn't.

TCP MD5 has been used for decades to protect BGP, and exactly because it's still safe there's been no push to add TCP-AO.

And it inherently requires kernel support, because it's part of TCP, not the application.

I would have preferred TCP-AO (RFC5925), not TCP MD5 (RFC2385), but the former is not supported anywhere.

See more at https://blog.habets.se/2019/11/TCP-MD5.html

(I should have added this link in my comment, but I forgot I wrote a blog post on the topic)

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

#139
post #76

Earlier quoted context omitted.

It's not a joke, BGP servers used to authenticate each other with this in the late 90s. This was also before NAT was really a thing.

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?

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

#140
post #73

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

Is this just spiped with MD5 instead of HMAC-SHA256? https://www.tarsnap.com/spiped.html

No, this is part of the TCP layer, which is why it can even protect against RST packets.
Post reply on HN