Dear PJP, in the ship, there is a hole. You are waving the flag
"unsinkable" instead to stop the flow and screaming: "The flow could be
stopped later!".
You dismiss my arguments without argument, just dismiss them. Unbelievable.
Is this about security or about your ego? Could do you agree that we
should be worry about other things you claimed first? Are you able to
underestand that your shoot badly missed the point? Seems not and this
is why the security disasters happened all the time.
Milan
Dne 12.1.2015 v 18:20 P J P napsal(a):
On Monday, 12 January 2015 10:06 PM, Milan Keršláger wrote:
No. It improves nothing. This is step backward.
It gaves bad signal to the user ("strong root password is not needed").
Wrong interpretation.
It does not mitigate the BF attack. The original and main reason was to
mitigate BF even "P J P <pjp@xxxxxxxxxxxxxxxxx>" told us here
that not.
No! Again, intention is to keep malicious users from gaining 'root' access via BF attacks. It is quite similar to why we run services as non-root users, instead of root. If at all break-in happens, it is still a non-root user.
The PJP told us that this is like SELinux or firewal. But firewall block
all trafic. But SELinux does not allow to obey the rules it raises. And
"PermitRootLogin=no" still allows BF
Which part of 'PermitRootLoing=yes|no' says anything about what to do with non-root account? It is not a mitigation for brute force attacks. The option merely says whether to allow remote root login or not.
(which is hard to prove as I demonstrated before because it will lead to use much
less quality passords for root and normal users too).
That's a hypothesis.
If you really want to improve security and mitigate BF attacks against root, do this:
A) do not run SSHD by default
That's a non-option.
B) install a script by default to bann repeated login failures
(there are many around here, just test them and ship one).
MaxAuthTries option could help with that.
---
Regards
-Prasad
http://feedmug.com
--
Milan Keršláger
http://www.pslib.cz/ke/
http://www.nti.tul.cz/wiki/Milan.Kerslager
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
