[fortran77]

Wordpress is a great example. He cites

> There is a long-standing security recommendation to change WordPress's default database table prefix to a random one. For example, wp_users becomes wp_8df7b8_users. This is often dismissed as "worthless" because it is security through obscurity.

I found that just changing the default URL for the wordpress login from the usual wp-admin to anything reduces by several orders of magnitude the number of scripts that try your site for the most common vulnerabilities---something that happens constantly for any site on the web, once a minute or so.

[i_think_so]

Same thing as changing your ssh port to something random. It's a trade-off with the convenience of knowing that all of your servers are listening on port 22 and you won't need any customizations in scripts or whatnot. But there are ways to mitigate much of that.

On the benefit side, mitigating most of the computational load, log analysis load, how much are the baddies poking me while I sleep load, etc...all of these together make changing such defaults a slam dunk IMO.

[kortex]

This should be immediately intuitive to anyone who spends more than 5 minutes looking at firewall traffic of something public. 99.9% of the bots' requests aren't doing sophisticated penetration attacks, they are blasting all the low hanging fruit: the common ports, the common wordpress endpoints, the common bobby tables style sql injections and xss attacks.

[Ekaros]

Looking at logs of recently deployed web service. There is large amount of same attacks. Just sprayed all over it. So just for example adding more obscure path could slightly slow down things if the version hosted is ever exploitable. Not that it will save from more sophisticated attacks.

[Fnoord]

Security through obscurity isn't security. It could be a method to reduce noise, but by doing so, you also have less eyes to watch over. If you'd pay for a blackbox pentest, and the pentester doesn't find your OpenSSH server running on a different port, then that doesn't tell you anything about the security of your OpenSSH server. In a whitebox pentest, they'd know about it beforehand. So, do you want to test the security of your OpenSSH server, yes or no?

There's a very simple method to reduce spam in OpenSSH server logs: whitelist IPs of those who require access (could be ranges, too), and centralize over a jumphost. And something like Shodan (and friends) would find your OpenSSH server running on a different port anyway. But it wouldn't find it if you were using whitelisting of IPs of those who require access. There is, for example, no valid reason that people in China or Russia need to connect to your OpenSSH server. Why allow them to? Don't. I don't allow traffic from any IPs allocated to China or Russia, among a couple of other countries, and I don't feel like I am missing out.

Another one is port knocking. Anyone who has read access over the network between client and server can figure out the port knocking process, including a hostile actor who does a MITM (with for example a rogue WiFi AP).

So what happens is improper security (security through obscurity) means people don't apply real security measures (such as IP whitelisting). And that is why security through obscurity is bad.

As for Wordpress, the default settings and default Wordpress is quite secure these days (have been this way for at least 10 years). It is all the bells and whistles in the form of addons which are the culprit.

[i_think_so]

> Security through obscurity isn't security. It could be a method to reduce noise, but by doing so, you also have less eyes to watch over. If you'd pay for a blackbox pentest, and the pentester doesn't find your OpenSSH server running on a different port, then that doesn't tell you anything about the security of your OpenSSH server. In a whitebox pentest, they'd know about it beforehand. So, do you want to test the security of your OpenSSH server, yes or no?

If your pentester can't find your sshd on a different port: 1) that is prima facie evidence that it works for a similar (low) skill level of attacker, and 2) you should fire that pentester. I'll leave the reasoning as an exercise for the reader.

> I don't allow traffic from any IPs allocated to China or Russia, among a couple of other countries, and I don't feel like I am missing out.

Now yer talkin'! As a blanket policy, if you have no valid users outside of your own nation and no expectation that will change, why not block everybody who isn't local?

(Of course, that just means any Russians and Chinese who do manage to attack you may be actual spooks, so if that happens you're pwned anyway. ;-) But you'll have cut down on your security logs considerably.)

> Another one is port knocking. Anyone who has read access over the network between client and server can figure out the port knocking process, including a hostile actor who does a MITM (with for example a rogue WiFi AP).

While I appreciate the fact that you're thinking outside of the typical box with regard to threat modelling, such an MITM attack is quite a few orders of magnitude more intentional of an attack than the rest of the crap the average systems/security admin has to deal with. In the case of a non-targeted (ie. not against a specific user or org) you're looking at a malicious network operator, which is far more sophisticated than 99.x% of the bulk scanning and attacks most admins see. In the case of a targeted attack we're talking about funded and probably successful organized crime at the very least, and possibly even nation-state intel orgs. Only motivated, professional attackers tend to get off their butts and travel to a different location to conduct an operation like that.

Kudos for recognizing such a problem, but using that as an excuse not to employ a powerful security technology such as port knocking is rather throwing the baby out with the bathwater. If you're going to be that defeatist, just airgap the system and be done.

Now, if you are willing to go through the effort of whitelisting IPs (which, I suspect, you haven't done yet, or you'd already loathe doing it and not recommend it), the sane way of going about that is to set up a VPN and whitelist the IP of the gateway. Otherwise you've opened up an administrative can of worms that is bad indeed. Nobody wants to have to keep track of Joe Blow's home IP address, which changes weekly at least, for some whitelist.

[Fnoord]

Well, perhaps what happened was they tripwired which is realistic in a blackbox test. If you'd whitelist an IP range from a pentester, you are on greybox testing area already.

There's another reason to not allow to/from such countries: malware (e.g. phishing).

But what they do instead is use residential proxies or VPS. And I happen to live in a country where they like to rent such.

I have done whitelisting of IPs. But I have a solid ISP who notice me beforehand when my static IPv4 changes, they also provide IPv6. One admin had DHCP, so he was there whitelisted in a CIDR range (on the jumphost). Which is also why I said you need to consider to whitelist a range. When I had the same ISP in different country (Liberty Global daughter) I had a static IP because my router was (at my request) in bridge mode. What you do in PF is IP lists which can be reused (anchors), and something like OPNsense allows to configure such automatically. You can even use dynamic DNS here, having your admin update it should the need arise. Then you do not need some kind of CIDR range.

The thing with all those scanners though is: they wouldn't get in if OpenSSH ran on 22 and Wireguard on 51820. It just reduces the noise in logs.

[pants2]

Nice. If you do the opposite of what WordPress does for security you're probably on the right track.