"Getting reports of brute force attacks is useful, but is not an indication of bad security. Hiding the reports under the carpet does not increase security either."
I didn't say reports increase security, and Fail2ban does more than just reporting, it actively blocks brute force attacks. It's a bit difficult us discussing the merits of certain security measures when you keep focusing on the irrelevant as if those were my security suggestions - it's almost as if you're trying to 'death by a thousand paper cuts' my whole post simply to win an internet argument <_<
"Preventing brute force attacks is not the bare minimum. The bare minimum is to not be vulnerable to brute force attacks in the first place. ssh already has built in protection for this, and it slows brute force attacks to the point where such an attack is impossible in practice, unless you have weak passwords. Mandate large enough keys only, ban passwords, and you're done. Allow password authentication is your real security vulnerability here. Patching over it with fail2ban just hides the issue."
For SSH, you'd be right. But as I've repeatedly said, not all services offer key based log ins and sometimes there's a business requirement for password log ins on systems that could be managed with keys. You're original arguments were about usability yet the arguments you're making now are the lest flexible suggestions raised thus far!
"I do understand how fail2ban works. "Just" monitoring logs isn't good enough. The data that appears in logs is not generally considered to be a security sensitive channel. It's string data with poorly defined delineation. It should not be trusted for automatic use, since every channel that dumps data into log files is not vetted for security."
Logs are fine for parsing as you have to be compromise before the logs are comprimised. But which point, it's already too late.
"I disagree. You claim I'm advocating security by obscurity, but you're the one who seems to think that hiding version strings gains in security. That's security by obscurity, since you can determine the version of software by observing its behaviour (or just not caring and trying your attack anyway)."
In theory I'd agree with you, however a great number of compromised systems were attacked by opportunists scanning version numbers looking for boxes to target with known vulnerabilities. Plus, and once again I'm having to repeat myself, those specific changes I advised are actually required to comply with many compliance laws (eg PCI compliance, required if you make finance transactions in the UK).
"I'm not advocating complacency. We just disagree on what complacency is. I claim that if you keep your software up to date (easiest if you do follow distribution defaults), then you are sufficiently secure. The overwhelming majority of security compromises happen because people fail to run updates."
There's no such thing as 'sufficiently secure' as that only depends on the attackers targeting your system. Today you might be 'sufficiently secure' because your box has not been spotted by any keen attackers, tomorrow might be different.
Also, I'd be more inclined to agree with you if all of the examples you've given weren't off topic from the points I raised or just incorrect (eg changing Apache config being dangerous and/or hard, fail2ban reducing usability, etc).
"The second largest cause is because of vulnerable misconfigurations that people have introduced."
I'd go along with that. I've often said 'users are the biggest security risks' :)
"Only a tiny fraction of compromises come through a default distribution installation that your hardening would catch, and these holes are rapidly patched by vendors and a simple update will close them."
None of the configurations I mentioned (bar the list of paranoid ones) fall into that category; non-optimal configuration isn't a hole that gets patched. Plus even if it was, it wouldn't be fixed with software updates as package managers tend to avoid over-writing live config files else they'd risk doing more damage than good.
"I think that it is much more likely that you'll open the second cause (an introduced misconfiguration) if you try hardening and you don't know what you're doing. Which is why I recommend sticking to distribution defaults."
You can't make a system less secure by changing the settings I recommended as the distro defaults are already on the most open defaults. Plus, and once again I'm repeating myself, the configurations I'm recommending are incredibly easy to implement.
I find it odd that we're actually arguing about whether it's worth making the most basic of changes based on the assumption that those people in question are stupid and their box will probably be ok. Surely a better approach would be to suggest optimisations; guiding them through the process if needs be? After all, it's too late to regret using the defaults if and when you get hacked (and in my line of work, I've had to fix quite a number of boxes where the sys admins have been content just running with the default settings).
"I find it odd that we're actually arguing about whether it's worth making the most basic of changes based on the assumption that those people in question are stupid and their box will probably be ok. Surely a better approach would be to suggest optimisations -guiding them through the process if needs be."
Not unless we're people with excellent reputations that "those people" can recognise, or it is possible to determine that people with these excellent reputations endorse our advice. Otherwise we're just adding to the muddle of information on the Internet, some of which is bad, some of which is good, and it is impossible for non-experts to tell the difference.
My argument is that the distribution is such a reputable source, and that a random article upvoted on HN isn't. If a distribution ships insecure defaults, then you should petition them to fix the defaults rather than publishing "fixes" elsewhere. You'll have to fight your corner, of course, against a bunch of people who might differ from you in your opinion about what is and isn't secure :)
I didn't say reports increase security, and Fail2ban does more than just reporting, it actively blocks brute force attacks. It's a bit difficult us discussing the merits of certain security measures when you keep focusing on the irrelevant as if those were my security suggestions - it's almost as if you're trying to 'death by a thousand paper cuts' my whole post simply to win an internet argument <_<
"Preventing brute force attacks is not the bare minimum. The bare minimum is to not be vulnerable to brute force attacks in the first place. ssh already has built in protection for this, and it slows brute force attacks to the point where such an attack is impossible in practice, unless you have weak passwords. Mandate large enough keys only, ban passwords, and you're done. Allow password authentication is your real security vulnerability here. Patching over it with fail2ban just hides the issue."
For SSH, you'd be right. But as I've repeatedly said, not all services offer key based log ins and sometimes there's a business requirement for password log ins on systems that could be managed with keys. You're original arguments were about usability yet the arguments you're making now are the lest flexible suggestions raised thus far!
"I do understand how fail2ban works. "Just" monitoring logs isn't good enough. The data that appears in logs is not generally considered to be a security sensitive channel. It's string data with poorly defined delineation. It should not be trusted for automatic use, since every channel that dumps data into log files is not vetted for security."
Logs are fine for parsing as you have to be compromise before the logs are comprimised. But which point, it's already too late.
"I disagree. You claim I'm advocating security by obscurity, but you're the one who seems to think that hiding version strings gains in security. That's security by obscurity, since you can determine the version of software by observing its behaviour (or just not caring and trying your attack anyway)."
In theory I'd agree with you, however a great number of compromised systems were attacked by opportunists scanning version numbers looking for boxes to target with known vulnerabilities. Plus, and once again I'm having to repeat myself, those specific changes I advised are actually required to comply with many compliance laws (eg PCI compliance, required if you make finance transactions in the UK).
"I'm not advocating complacency. We just disagree on what complacency is. I claim that if you keep your software up to date (easiest if you do follow distribution defaults), then you are sufficiently secure. The overwhelming majority of security compromises happen because people fail to run updates."
There's no such thing as 'sufficiently secure' as that only depends on the attackers targeting your system. Today you might be 'sufficiently secure' because your box has not been spotted by any keen attackers, tomorrow might be different.
Also, I'd be more inclined to agree with you if all of the examples you've given weren't off topic from the points I raised or just incorrect (eg changing Apache config being dangerous and/or hard, fail2ban reducing usability, etc).
"The second largest cause is because of vulnerable misconfigurations that people have introduced."
I'd go along with that. I've often said 'users are the biggest security risks' :)
"Only a tiny fraction of compromises come through a default distribution installation that your hardening would catch, and these holes are rapidly patched by vendors and a simple update will close them."
None of the configurations I mentioned (bar the list of paranoid ones) fall into that category; non-optimal configuration isn't a hole that gets patched. Plus even if it was, it wouldn't be fixed with software updates as package managers tend to avoid over-writing live config files else they'd risk doing more damage than good.
"I think that it is much more likely that you'll open the second cause (an introduced misconfiguration) if you try hardening and you don't know what you're doing. Which is why I recommend sticking to distribution defaults."
You can't make a system less secure by changing the settings I recommended as the distro defaults are already on the most open defaults. Plus, and once again I'm repeating myself, the configurations I'm recommending are incredibly easy to implement.
I find it odd that we're actually arguing about whether it's worth making the most basic of changes based on the assumption that those people in question are stupid and their box will probably be ok. Surely a better approach would be to suggest optimisations; guiding them through the process if needs be? After all, it's too late to regret using the defaults if and when you get hacked (and in my line of work, I've had to fix quite a number of boxes where the sys admins have been content just running with the default settings).