Seeing how fast people will probe you after you get a new TLS certificate
utcc.utoronto.ca
utcc.utoronto.ca
Thanks for the suggestion. I'll definitely consider that trick with my upcoming setups.
For personal use, I do feel that Wireguard or managed Wireguard setups like Tailscale are so easy to use that putting everything behind a VPN is cheap insurance and even convenient, since it takes care of NAT traversal for you.
I also use blackholing (with fail2ban) and non standard ports (for ssh) - but just as a way to quiet down log files rather than ascribing much ion the way of security benefits to them.
Just switch to IPv6: good luck scanning a /64. :)
:-)
I had IPv6 on my home desktop for several years before I switched ISPs a few months ago.
My new ISP does not offer IPv6 on their residential network… but their mobile telco subsidiary gives it out to smartphones (IPv6-only). ¯\_(ツ)_/¯
90% of desktops/laptops get a 192.168.0.x address. Maybe some do ipv6 as well
Cyber criminals follow patterns, starting with very low-effort trolling for new services without much defenses. Bots scan the internet for open services, enumerate them, and try to gain access. If they find some, they will use a tiny amount of effort to see if the target might be worth exploring. If it seems profitable, the cybercriminal will spend more effort on things like account enumeration, login brute force, scanning for commonly exploitable methods, phishing. The more they find, the more they're willing to invest in exploiting it. But a bot can perform a ransomware hijacking of a newly detected open service all on its own, so it doesn't take much.
Simple mitigations can be very effective in holding back their interest. Captchas, rate limiters, error pages with no information leakage, block lists of low-reputation IPs, or outright blocks of countries you don't do business with. They make the difference between 50k login attempts per minute, or crickets.
Don't use port knocking tho. It technically works, but is embarrassing, like a grown man in a trilby. Something else (like rate limiting combined with certificate auth) will be more effective and less weird.
If you know a site has a 4-words policy, the xkcd pw has very low entropy, but if you use this strategy on a "any pw goes" site, a bruteforcer would have to test all lengths upto 25 chars before finding yours (sort of).
So in the port-knock case, it is probably a rather poor method in the specific case that I am on some remote network, and the evil 3rd party is actively sniffing my traffic from my client to my server and can record the knocks. If I have a simplistic knock sequence and they sniff it, they can replay it and get access to my https. But, if we are talking about some 3rd party that only knows a service may be up on the host newly.minted.cert.ccTLD, then it is FAR less likely that they can ALSO sniff my port knocking sequence and start abusing my new TLS service. The chances become almost ridiculously low for this to occur.
So I agree that simplistic port knocking is sort of bad in the long run for cases like "I am often on a hostile network but still want to talk to my home server securely" but would work wonders for "soon after the cert is signed, someone scans my TLS boxes ip".
Somewhat related, I've never set up port knocking but I've been wondering how hard it would be to set up TOTP-flavored port knocking. The basic idea would be to select the pattern of "knocks" the same way TOTP generates a code, I'm not sure how much it would improve things though.
How so? Iirc, the entropy calculations assume that the attacked is aware passphrases are used. The eff-long word list often used for xkcd-style passphrases has 7776 words. So on average it would take 7776^4/2 attempts to guess one (randomly generated) 4-word passphrase, comparable to a truly random 8-9 character password with special chars. As the comic points out, people tend to be pretty bad at remembering random sequences of characters and therefore often often use combinations of common words and apply non-random substitutions and patterns, resulting in much lower entropy for those passwords.
Of course, everyone should use a password manager in the first place, but for cases where people don't or they need to reliably remember it (master passwords and critical ones), xkcd-style passphrases are a good and secure option.
Anyone even thinking about port knocking should look at fwknop.
This of course drives all sorts of chrome browsers and mitm stuff bonkers.
So the next time someone asks why you dont want to buy into the dns/cert route, tell them this. Inb4, i know the whole subsequent argument chain, nevertheless, this reduces the activity. yes, yes it does.
Does it reduce it quantifiably, and usefully, long term?
I've had the discussion about running SSHd on a non-standard port with a few people over the years. I've never been convinced that saving a bit of log file space is worth the reconfiguration time, nor that the security benefits are significant (assuming a secure config otherwise of course) given that at least some sophisticated actors prove I non-standard ports for the presence of services.
sigh It's not the log file space, it absence of failed attempts in the logs.
Especially if there's a suspected incident or a new vulnerability announced, I'd much rather be reading port 2234 sshd logs that port 22 sshd logs - far less haystack to wade through looking for needles.
And as another comment mentions, every time an sshd zero day is announced, pretty much the entire IPv4 address space gets probed on port 22 within about 30 minutes. A non standard port number _might_ buy you an extra hour or three if you've got a vulnerable sshd. But don't rely on that - someone's bound to have portscanned you recently enough and knows you've got OpenSSH_8.2p1 listening on port 2234 (or whatever) and they won't be far behind the whole-internet port 22 exploit probes.
But it's nice to have the logs reasonably clean, makes it easier to see real problems.
This is relatively easy to do with Ansible (or whatever).
My main concern as a sysadmin in a company is user training and telling folks to use the non-standard ports.
If I could use SRV records for 'service (port) discovery' that'd be helpful.
Could you ship and manage SSH config files for your users?
It exposes part of the domain, but none of the services.
If you want to be even more secure, you could null-IP the wildcard and only allocate IPs for subdomains that you use.