F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Stephen John Smoogen]

On 12 January 2015 at 06:05, P J P <pj.pandit at yahoo.co.in> wrote:

> > On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote:
>
> > You are (instead of completly mitigating), only raising complexity a
> > little bit (ie not completly avoiding), which is what is "Security
> > through obscurity" about (ie. by hiding source code, the attacker only
> > solve more complex problem - debugging machine code).
> >
> > One more time: The system can be cracked by BF attack only if there is a
> > weak (root) password.
>
>   Sure. As guessed, you misunderstood the intention. The feature is _not_
> a remedy against brute force attacks. But it is a remedy for keeping such
> attackers from gaining 'root' access on remote machines. The feature says,
>
>
I don't see how this is the case. All we have done is move the first line
of the root-kit script to calling sudo via the password that was used to
open the account up. Since many of Linux systems are single user boxes.. it
is most likely going to work. If it fails then the majority of them just
dump the warning email in /var/spool/mail/root which never gets read (from
the number of boxes I have had to clean up).

And from looking at the sophistication of various worms these days.. they
are a lot smarter about guessing who owns the box and then trying various
smart choices (since Fedora will select ssmoogen as my name it has shown up
more often in brute forces by systems which I own).


>   "...Disabling remote root login by setting PermitRootLogin=no would help
> to harden Fedora systems, moving it an inch closer towards 'secure by
> default' future. Users can have non-root accounts with weak passwords too,
> yet disabling remote root login keeps an attacker a step away from getting
> full control on a system..."
>
> The feature helps to _harden_ Fedora systems. Same as filtering traffic
> via firewall or restricting undue access via SELinux etc.
>
>
> > If you disable remote root login (bacause users are using weak crackable
> > password), you are saying to the user: "Happily use simple password
> > because you are safe even that!". And because when admin password could
> > be simple then the user password will be more simpler (this is
> > average-user-logic) and the BF against the system will succeed more
> > easily (even the login name will need to be guessed or picked by another
> > way). So your solution is potentionally more dangerous than current
> > situation.
>
>   That is a lot of speculation and hypothesis. In now way does this
> feature imply or indicate to users that they can use weak passwords.
>
>
I was going to say it is an informed speculation.. I have actually had to
interview various people about weak passwords and why they chose them and
the largest excuse is "Well I don't need to have a strong password for
this.. its not like its root." [I have had this from Phd's in computer
science who thought it would be too hard for a script kiddie to know to use
sudo to get access.. and then had a lot of compromised computers. This was
in 2003-2004 so it is not a new problem.]



> > If you want to avoid the problem (ie avoid BF crack-in), disabling
> > remote root login is not the right way, this is simply not enough, this
> > does not solve the problem. There are better solutions I wrote about
> > already (prefferrably to not expose SSH to the wild by default).
>
>
>   Again, issue being addressed is not of brute force attacks. But that of
> such attacks resulting in gaining 'root' access to remote machines. They
> are two distinct issues.
>
>
They are only two distinct issues with dumb scripts which get smarter as
soon as the malware authors realize that they need to add some logic for
sudo or su access. Once there is a connection between the factors they are
linked.



> ---
> Regards
>    -Prasad
> http://feedmug.com
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150112/3e859c6b/attachment-0001.html>