Aaron Toponce schreef:

On Thu, Feb 24, 2011 at 04:51:30PM -0600, Boyd Stephen Smith Jr. wrote:
For example, you might let one user "sudo" without a password, disable root
logins via ssh, have every other user (including root) be disabled in
/etc/shadow, disable password logins via ssh, and have all other non-root
users have a bogus shell like /bin/false. That user of course only have one
entry in authorized_keys, and it is a 4242-bit key.


Or you could an SQL injection, or you could attack a web form, or you
could...
SQL injecting and web forms will not work for ssh directly, unless you
have a very poorly configured apache+mysql-config. Of course there are
ways of obtaining someone's password.
Shared key seems more secure, with a good policy for guarding the keys.
I am not arguing that. It is just that when you disable root logins
there's in principle an extra layer of protection. This 'in principle'
of course only helps when done properly, thus not reusing passwords etc.
The fact that a compromised user account = a compromised machine is of
course very true. However, when detected it might be that the attacker
did not manage yet to get root permissions. Thus, it buys some time.


Sjoerd

On Fri, Feb 25, 2011 at 12:42:51PM +0100, Sjoerd Hardeman wrote:
> SQL injecting and web forms will not work for ssh directly, unless
> you have a very poorly configured apache+mysql-config. Of course
> there are ways of obtaining someone's password.

Heh. SQL injections can get you all sorts of things. The goal is to get
into the server via any route possible. If you leave the server open to
the outside world, disabling root login via ssh isn't granting you any
security.

> Shared key seems more secure, with a good policy for guarding the
> keys. I am not arguing that. It is just that when you disable root
> logins there's in principle an extra layer of protection. This 'in
> principle' of course only helps when done properly, thus not reusing
> passwords etc.
> The fact that a compromised user account = a compromised machine is
> of course very true. However, when detected it might be that the
> attacker did not manage yet to get root permissions. Thus, it buys
> some time.

There are many paths to root, once the attacker is successfully in.
Privilege escalation exploits, buffer overflows, brute force attacks,
insufficient input sanitization, you name it. Don't think for one second
that attackers don't have vulnerability lists that haven't been
reported. And don't think that as soon as they've broken in, you can
boot them out before any damage is done.

My point is, removing root logins via SSH is not hard security. It's
barely a speed bump to the talented and dedicated. If you want a secure
server, then learn firewalls, mandatory access control, ACLs, chrooted
jails, information intropy for passwords, and keep your damn server
patched. As Anonymous has clearly shown lately, if you're a target,
you'll get damage, one way or the other. Even if all they can do is a
DDOS. Taking root logins out of SSH isn't going to buy you any security.

--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o

On Feb 25, 2011 8:40 AM, "Aaron Toponce" <aaron.toponce@gmail.com> wrote:

>

> On Fri, Feb 25, 2011 at 12:42:51PM +0100, Sjoerd Hardeman wrote:

> > SQL injecting and web forms will not work for ssh directly, unless

> > you have a very poorly configured apache+mysql-config. Of course

> > there are ways of obtaining someone's password.

>

> Heh. SQL injections can get you all sorts of things. The goal is to get

> into the server via any route possible. If you leave the server open to

> the outside world, disabling root login via ssh isn't granting you any

> security.

>


I'll bite, please explain.