I agree, for example: When a WordPress vulnerability is found, millions of sites are at risk. The large installation base is enough incentive for people to relentlessly scrutinize WordPress for vulnerabilities.

Your home-made CMS isn't going to attract attackers because the spoils are limited to one site, and the code isn't readily available.

That doesn't mean your CMS is more secure; it probably isn't. But it's going to take a focused effort to attack, and an exploit becomes less likely.

Even making minor changes to the Wordpress URLs from the defaults is enough to avoid getting hit by most (if not all) of the automated exploit I see on a day to day basis.

Why would you ever want to be vulnerable to targeted attack while only keeping dragnet ones at bay?

Also such measures do not help any kind of a system that has to be really exposed. Want to hide your http and mail server behind a port knocking mechanism? A rarely supported or proprietary TLS method only?

It doesn't make you more vulnerable to targeted attack, so why would you not want to additionally keep dragnet ones at bay?

Because it's not doing anything to stop dragnet attacks either!

Maybe "dragnet" wasn't the best term to use. I'm not talking about the NSA, but rather about automated brute-force attempts (think: random attempted ssh connections from the internet).

With regards to that, not stopping automated attacks in general is fully-independent of being a less appealing target for such attacks. The latter -- even on it's own -- improves security.

It's not doing anything to stop brute-force attempts! SSH keys already stop that attack cold!

So is this an argument that defense in depth is not a worthwhile strategy as long as you have a single "really good" layer of defense?

No, it's an argument not to waste time with pointless layers that impose no significant costs on attackers. Surely, you can't believe that "defense in depth" justifies arbitrary layers, or you'd also advocate for ROT-13 tunnels.

No, but I disagree that running sshd on an alternate port is an arbitrary layer. It is PROVEN that it prevents the automated mass scanners from even attempting to login. This you admit yourself when you mention the reduction in log noise.

You are correct that a properly configured sshd has nothing to worry about with respect to these mass scanners. However, can we guarantee that we'll never make a configuration error? You're also correct that a pre-auth sshd vuln would be a HUGE deal. But can we guarantee one will never happen? Do you disagree that if a misconfiguration or a world-changing vulnerability were to happen, that a little time more to deal with it would be helpful?

If I run something that is in any way vulnerable (whether via bug or misconfiguration) on port 22, it will be found within minutes (based on how often I see that port getting scanned today). Unless I'm being specifically targeted, an sshd running on an arbitrary port isn't going to get hit until/unless someone is running full port scans across the internet looking for it. I don't understand how you can argue that this is worthless. A measure that isn't useful against a determined and targeted attacker can still be useful. The adversaries that most of us face in the real world are looking for the path of least resistance, not access to our specific systems.

By the way, this is the same reason I lock my door even though there’s a glass sidelight right next to it. Any burglar who wants to get into my house can do it in about 5 seconds by breaking that sidelight. But that doesn’t mean there’s no value in keeping out the mischievous neighbor kids who are just rattling doorknobs and looking for a place to steal booze from.

I wouldn't think of alternate port as any kind of layer whatsoever. It defends against the horde of ants that are knocking on any open port 22. It does not defend against the kind of attack that you should worry about--that of a sophisticated, patient well funded attacker.

Moving from port 22 to $RANDOM will only net you annoying log bloat from things that you don't really care about.

You're assuming everything is properly configured. A bug-free setup is essentially impossible.

The claim is that obfuscation makes it less likely that a mistake will be spotted by an attacker.

To be clear, I agree with you to the extent that a properly configured SSH server with good keys and no 0-day exploit is more effective than what I'm proposing. My point is rather that such a setup makes a lot of assumptions (key exchange, configuration, secure updates, etc...) and that obfuscation is a complementary security layer for when those things occasionally fail.

"A bug free setup"? Don't use passwords. Done.

Come on, now I'm starting to suspect you're commenting in bad faith.

Just to reiterate, SSH was an example of the general problem that is misconfigured/buggy software. OpenSSH is certainly one of the most secure programs I'm aware of, but the same can't be said for things like wordpress.

Eventually, something gets messed up (if only momentarily), and being nonstandard makes you less susceptible to scripted breaches.

We can debate whether the tradeoff is worthwhile (and in many cases it's not), but it's a valid gosh-darn secruity layer!

If you can't deploy passwordless SSH, you have problems port-knocking can't solve.

I'm at a loss for words. I implore you to re-read this comment thread and try to understand what I'm saying.

You're responding to an argument I haven't made.