Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hi, That's not security through obscurity. It's a way to limit the exposure to a brute force attack with an a privileged account. Also this allows the user uses a different account so remote attacks that user is unknown and can not be used to brute force delimiting more exposure. Most instances cloud providers do this basically, like EC2 where the normal user for a predefined fedora cloud instance is 'fedora' ( public key-based authentication). Whenever possible need to limit remote access, and one of the most important points are the privileges of these remote access. It must be guaranteed a minimum of security for all users (Desktop/Cloud/Whatever). Should be the responsibility of the administrator to enable this remote access. -- Francisco Alonso. http://twitter.com/revskills PGP: 0xE2E64DCA -- On Mon, Jan 12, 2015 at 10:40 AM, Milan Keršláger milan.kersla...@pslib.cz wrote: No, this is not good idea as I wrote few minutes ago because it does not improve security, it just provide feeling of better security, see: https://en.wikipedia.org/wiki/Security_through_obscurity I wonder why no-one responded like me, because this was discussed many times ago. Well maybe many times since 1995 (when SSH was born) and maybe I'm a little bit old so I read it many times again and again. It seems like SSH does not make padding sufficiently, but this changes nothing on what I wrote. Disabling root loging does not solve the problem and it profides only false feeling of security. M.K. Dne 12.1.2015 v 09:56 P J P napsal(a): Hello, On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote: Earlier in the discussions I was told that this is not really an issue: in production, about every server with remote access also has a KVM. Often not the case in small business or third party hosted environments. Without remote ssh, box is unmanageable. Even if you want to do key-based authentication rather than password, you still need to use password initially to get the key onto the remote box. If you use cloud-init you can specify an initial public key that it inserts against, or even auto enrol it in a central auth system like IPA and hence not ever need a password. So, the major issue(or blocker should we say?) is the virtualized deployments. If there is no solution in sight, maybe last resort is to enable remote root login, possibly in the '%post' install section of the kick-start file. Does it seem like an appropriate solution? --- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Francisco Alonso. http://twitter.com/revskills PGP: 0xE2E64DCA -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Delimit the remote access to users with privilege is not in any case based Security through Obscurity. Obviously the best option for delimiting access is disabled by default SSH. I consider before taking such drastic measures that may affect users of cloud, is more than reasonable disable access to users with administrative permissions.I will not go on reasonable local situations like using custom rules for SELinux or firewall rules (when the firewall disabled by default). Delimiting access to SSH is not only through the LAN/Internet network, it is also important to prevent a local user where SELinux rules or whatever will not let you make a su/sudo/whatever - root. And They can simply ssh localhost. - Do not run sshd by default: It would be great in the installation this was an option to enable it. Better to go step by step and see what happen with the users and how this affect them without drastic changes. - Install a script like fail2ban: So you need a default firewall enabled ( What do we have? I know another thread about fw disabled by default..). This really affects more an a user than disable remote root login. Do we want to help the user to have a secure distribution by default? Let's start by being aware that we must define certain things that are not commonly used. Is more common users with weak passwords than users using ssh as root or using rsync.. On Mon, Jan 12, 2015 at 5:27 PM, Milan Keršláger milan.kersla...@pslib.cz wrote: Dne 12.1.2015 v 15:46 Przemek Klosowski napsal(a): There still needs to be an administrative access to the system, and the most common implementation by enabling 'sudo' on the non-privileged account. So, in a sense you are both right: this feature is just a small step rather than a security panaceum, but it does bring real improvements in several areas: - increases difficulty of the attack by banning stupid automated BF attacks on root - improves accountability for administrative actions (we know which admin messed up :) - allows more granularity in granting elevated privileges across a set of machines and admins No. It improves nothing. This is step backward. It gaves bad signal to the user (strong root password is not needed). It does not mitigate the BF attack. The original and main reason was to mitigate BF even P J P p...@fedoraproject.org told us here that not. See his writings here: https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html, https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no This is simply very bad security misconception. 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 and still allows easily to login as another user and do su/sudo even maybe (!!!) not so easily (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). All this rumor is trying to tell us that it improves security, but does not. It provides false feeling of improved security and this is very dangerous (ie. like does Security through Obscurity). If you really want to improve security and mitigate BF attacks against root, do this: A) do not run SSHD by default B) install a script by default to bann repeated login failures (there are many around here, just test them and ship one). These are real steps forward as it will really mitigate BF for all accounts in the system. -- Milan Keršláger http://www.pslib.cz/ke/ http://www.nti.tul.cz/wiki/Milan.Kerslager -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Francisco Alonso. http://twitter.com/revskills PGP: 0xE2E64DCA -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Hi, I've been testing in advance to make mass rebuilds changing macros and the results are pretty good (I mean x86_64 f20, f21 + grsecurity custom kernels). It is clear that we will find regressions, we just have to start and test it.. It is an important and necessary change. If anyone is interested would be important to look at uClibc and musl (Alpine Linux is based in this one). http://www.etalabs.net/compare_libcs.html Note that other distributions are doing an excellent job in hardened profiles like Gentoo or more actual OpenSuSe Gardened: http://wiki.gentoo.org/wiki/Project:Hardened_musl http://wiki.gentoo.org/wiki/Project:Hardened_uClibc https://github.com/kdave/openSUSE-gardened/wiki/openSUSE-gardened We have to work on mitigation rather than patching and trust not responsible maintainers for some packages. This includes thinking seriously about to have a kernel with grsecurity patches. Cheers, On Sat, Jan 10, 2015 at 4:19 PM, Peter Robinson pbrobin...@gmail.com wrote: On Thu, 2015-01-08 at 08:47 -0500, Paul Wouters wrote: On Thu, 8 Jan 2015, Dhiru Kholia wrote: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. +1. This view is rapidly gaining traction and visibility in recent times. Can we throw prelink out as well when we do this? Prelink is already gone. We haven't been running it since F19, IIRC. It's not completely gone, there's still a number of packages that run it as part of the install or build process because I've had to fix ppc64le/aarchh64 package builds because we don't have it at all on those platforms. I think we also ship it by default. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Francisco Alonso. http://twitter.com/revskills PGP: 0xE2E64DCA -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
