full-disclosure - Re: Any update on SSH brute force attempts?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.GSO.4.43.0410190050230.28594-100000@tundra.winternet.com>
From: dufresne at winternet.com (Ron DuFresne)
Subject: Re: Any update on SSH brute force attempts?

On Mon, 18 Oct 2004, Raj Mathur wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >>>>> "Barrie" == Barrie Dempster <barrie@...oot-robot.net> writes:
>
>     Barrie> On Mon, 2004-10-18 at 06:41 -0500, Ron DuFresne wrote:
>     >> Why not just disallow root logins directly, and force someone
>     >> with a valid user account to su after getting a shell?  It was
>     >> my impression that was more standard, and if one has to allow
>     >> remote root directly, at least restrict it to specific systems
>     >> and users.  All the places I have worked for forced the su
>     >> after shell to root..
>
>     Barrie> I'm in agreement with this, as well as combining this with
>     Barrie> use of sudo for common functions requiring root privs
>     Barrie> (such as using tools requiring raw socks support for
>     Barrie> instance) meaning you rarely have to become root and the
>     Barrie> root account becomes slightly more difficult to
>     Barrie> compromise.
>
> Using su forces the use of passwords, which are difficult to manage in
> a multi-admin scenario.  For instance, you may have to give the root
> password to 3 different people (1 in each 8-hour shift).  What happens
> when one of these people leaves the organisation?  You change the root
> password and intimate the remaining two, as well as the replacement,
> of the new root password.
>

Not at all, if they are not on the list of admins that require root to do
their jobs, whose processes include a way to routinly change the passwd,
and distribute it in a secure manner <face to face>, then they don;t get
the passwd fer root.  Temp needs of root level access can be done through
sudo or similiar tools, and limiting what those users have access to.
anything more requires and admin to do the job and make sure it's done
correctly.  Oh, and the help desk is *not* on the list of those to whom
the root passwd should be made available.  They may end up distributing it
over the phone or via e-mails to just about anyone that calls for
access....

Thanks,

Ron DuFresne
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.