Secure root alias logins
To: suse-security@suse.com From: keith.anthony.roberts@bigfoot.com Subject: Secure root alias logins Hi everyone! Surely it would be more difficult for any attacker to break into Linux if they did not know the username for the root account? I just wondered if it was possible to make root logins MUCH more secure with the following suggestions. When a NEW installation of Linux is done, allow the root user to select their -*OWN*- unique username for the root account in YaST, instead of the default 'root' username. Disallow the use of username 'root' for ALL root superuser logins. When a superuser logs-in they provide their unique username that they choose when installing Linux eg. under YaST. Each login program would need to be modified to reject the username of 'root'. The login program then checks say, password file for the unique root alias name (provided by superuser at installation time) and matches this up with the root account. If a matching root alias and a valid password for that alias name are present, then the superuser gets logged into the root account. The root account need not be touched in any way. The superuser alias name is just used as a 'WRAPPER' to protect the username of root for login purposes only. Would this be feasable to implement? This may have been implemented already. If it has - please let me know. Thankyou - Keith Roberts.
On Wed, Jan 15, 2003 at 08:47:50PM +0000, keith.anthony.roberts@bigfoot.com wrote:
Surely it would be more difficult for any attacker to break into Linux if they did not know the username for the root account?
I just wondered if it was possible to make root logins MUCH more secure with the following suggestions.
When a NEW installation of Linux is done, allow the root user to select their -*OWN*- unique username for the root account in YaST, instead of the default 'root' username.
Disallow the use of username 'root' for ALL root superuser logins.
When a superuser logs-in they provide their unique username that they choose when installing Linux eg. under YaST.
Each login program would need to be modified to reject the username of 'root'.
Login programs should only use the username to lookup a uid. If that uid is 0 then the user is the super user. The name "root" is not important at all. Victor
On Jan 15, keith.anthony.roberts@bigfoot.com Surely it would be more difficult for any attacker to break into Linux
if they did not know the username for the root account?
[...]
When a NEW installation of Linux is done, allow the root user to select
their -*OWN*- unique username for the root account in YaST, instead of the
default 'root' username.
In fact you should disable remote login for root via password (and maybe
even with ssh key), and only allow a normal user to get root using su.
Your method is likely to break stupid/legacy programs and does not
increase security. Markus
--
__________________ /"\
Markus Gaugusch \ / ASCII Ribbon Campaign
markus@gaugusch.at X Against HTML Mail
/ \
Markus Gaugusch
On Jan 15, keith.anthony.roberts@bigfoot.com
Surely it would be more difficult for any attacker to break into Linux if they did not know the username for the root account? [...] When a NEW installation of Linux is done, allow the root user to select their -*OWN*- unique username for the root account in YaST, instead of the default 'root' username. In fact you should disable remote login for root via password (and maybe even with ssh key), and only allow a normal user to get root using su. Your method is likely to break stupid/legacy programs and does not increase security.
I agree with you, that disabling remote root login via ssh is an important security measure. It's also a fact that renaming the root account breaks at least some important programs on every distribution I know (being SuSE, Mandrake and Debian). But even if a public service, for example ssh, is configured not to let "root" login remotely, a security hole may enable an attacker to do so nevertheless. Therefore renaming the "root" login however CAN delay a successfull hack, just depending on the kind of security hole. This can give the administrator the time needed to fix the security hole. Actually renaming the root login is a security measure recommend in many papers about security around. So I would like to support this request, although it's IMHO not very likely to be implemented. There's just too much software involved. Best regards, Matthias
On Thursday, January 16, 2003 at 07:21:14 GMT +0100 (which was 12:21 AM where I live), thus spake Matthias Riese on the subject of "[suse-security] Secure root alias logins": Matthias> Actually renaming the root login is a security measure recommend in Matthias> many papers about security around. Not having seen these papers myself, could you kindly provide me with pointers to them? -- Best regards, Geordon mailto:gvantass@interaccess.com Your fortune: "Some days you're the dog, and some days you're the hydrant."
Geordon VanTassle
On Thursday, January 16, 2003 at 07:21:14 GMT +0100 (which was 12:21 AM where I live), thus spake Matthias Riese on the subject of "[suse-security] Secure root alias logins":
Matthias> Actually renaming the root login is a security measure recommend in Matthias> many papers about security around.
Not having seen these papers myself, could you kindly provide me with pointers to them?
See here: http://www.nic.com/~dave/SecurityAdminGuide/SecurityAdminGuide-all.html http://www.intersectalliance.com/projects/LinuxConfig/ http://www.gsu.edu/~wwwccs/security/secureos/security_tips_checklists.htm http://www.abtrusion.com/HardeningNT/10.asp Best regards, Matthias
On Thu, 16 Jan 2003, Matthias Riese wrote:
But even if a public service, for example ssh, is configured not to let "root" login remotely, a security hole may enable an attacker to do so nevertheless. Therefore renaming the "root" login however CAN delay a successfull hack, just depending on the kind of security hole. This can give the administrator the time needed to fix the security hole.
Most of the exploits out there don't care how uid 0 is called. The exploits spawn a shell/execute something with the uid under which the exploited program/daemon runs - it doesn't matter if it is called root, superuser or foo. If this is uid 0 the attacker can do what he wants on the system. The kernel itself has no conecpt about the names, all it cares about are the numerical user-ids. So the goal has to be to run as much as possible under different uids than 0, and to use services for which no working exploit exists/is known. I have yet to see an successful attack using the username "root" and the valid passwort without the admin beeing a complete moron. c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/)
Sven Koch
On Thu, 16 Jan 2003, Matthias Riese wrote:
But even if a public service, for example ssh, is configured not to let "root" login remotely, a security hole may enable an attacker to do so nevertheless. Therefore renaming the "root" login however CAN delay a successfull hack, just depending on the kind of security hole. This can give the administrator the time needed to fix the security hole.
Most of the exploits out there don't care how uid 0 is called.
[snipped much correct information] I never said, renaming root is the perfect security measure making all kinds of hacks impossible. Renaming root: - influences only a few types of attacks (don't think only of remote attacks) - for these types of attacks it probably only delays the successfull hack So I think it doesn't need to be discussed, whether renaming root improves security. It does. Only slightly, but it does. If renaming root was possible out of the box, one would probably use even this to enhance the security of his machine. At least it doesn't hurt. With renaming root being not possible out of the box, it's IMO not worth the effort fixing the software oneself. Best regards, Matthias
In fact you should disable remote login for root via password (and maybe even with ssh key), and only allow a normal user to get root using su.
Selecting permissions "paranoid" breaks this, as it removes the suid bit from su, thus preventing any normal user to su to root. A quick edit to /etc/permissions.paranoid fixes that. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
* Volker Kuhlmann wrote on Thu, Jan 16, 2003 at 21:13 +1300:
In fact you should disable remote login for root via password (and maybe even with ssh key), and only allow a normal user to get root using su.
Selecting permissions "paranoid" breaks this, as it removes the suid bit from su, thus preventing any normal user to su to root. A quick edit to /etc/permissions.paranoid fixes that.
I think it's nice to make SSH logins possible by key only, and having no (human) users on the machines if possible :) I trust more in a SSH key than in su :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Steffen Dettmer schrieb:
* Volker Kuhlmann wrote on Thu, Jan 16, 2003 at 21:13 +1300:
In fact you should disable remote login for root via password (and maybe even with ssh key), and only allow a normal user to get root using su.
Selecting permissions "paranoid" breaks this, as it removes the suid bit from su, thus preventing any normal user to su to root. A quick edit to /etc/permissions.paranoid fixes that.
I think it's nice to make SSH logins possible by key only, and having no (human) users on the machines if possible :) I trust more in a SSH key than in su :)
oki,
Steffen
why not disable su and root/ssh completely and use sudo instead? sudo has a simple configuration file and lets system users issue commands as root. the commands are limited to those permitted in the configuration file. so you have to login as an ordinary user and can use just those root-commands that your sysadmin has allowed you to use... greets, Christoph
why not disable su and root/ssh completely and use sudo instead? sudo has a simple configuration file and lets system users issue commands as root. the commands are limited to those permitted in the configuration file.
for paranoids like you it is best to disable root complete except in boot-scripts. disable su, root/ssh, sudo etc completely. but even this system won't be 100% secure! and if you want to (for example) install some new software you have to reboot (boot from cd or floppy) greetings Michael -- Der süsse Pinguin ist mir lieber als die kleinen weichen, die einem nur kaputte Fenster verkaufen
* Michael Heide wrote on Fri, Jan 17, 2003 at 00:15 +0100:
for paranoids like you it is best to disable root complete except in boot-scripts. disable su, root/ssh, sudo etc completely. but even this system won't be 100% secure!
But this system would be 100% non-administrable... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Steffen Dettmer
* Michael Heide wrote on Fri, Jan 17, 2003 at 00:15 +0100:
for paranoids like you it is best to disable root complete except in boot-scripts. disable su, root/ssh, sudo etc completely. but even this system won't be 100% secure!
But this system would be 100% non-administrable...
Adminstration would be done by first unplugging the network cable, then rebooting from disk or CD. That certainly requires physical access to the server, which is not always given... Best regards, Matthias
participants (10)
-
Christoph Illnar
-
Geordon VanTassle
-
keith.anthony.roberts@bigfoot.com
-
Markus Gaugusch
-
Matthias Riese
-
Michael Heide
-
Steffen Dettmer
-
Sven Koch
-
Victor R. Cardona
-
Volker Kuhlmann