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
Attachment:
signature.asc
Description: Digital signature