Cybersecurity

I stumbled upon this thread and one aspect of it got me thinking. As i am building a small Linux network right now for a friend i would like to hear your opinion on this.

I'd like to respectfully disagree. I think the Linux habit of disabling root login per default is wrong (not entirely good, more precisely) , based on the following reason:

It is easy to see that for private purposes, where one (or any other very small number) of systems is in play this restriction makes sense. It enhances system security and is therefore a good thing to have.

Still, apart from private usage there is the corporate usage of Linux systems. Administrating up to several hundreds of (maybe virtualized) Linux systems typically involves carrying out one command on several or all systems in parallel. If i want to know which systems have a certain package/version combination installed I'd issue some rpm-command on all systems, for instance, to find out which systems need a certain update.

To do so is basically impossible without having root access to the system directly. Yes, it would be possible to query the version information as a normal user in the example above - suppose this shows that 50 systems need a certain package to be installed. You need root to do and nobody wants to go through the motions of logging on to one system after the other, issue a "sudo su - root", enter his own password fifty times and then carry out a single command to actually install the package.

Probably every commercial Unix has provisions to make this a one-liner. In IBMs AIX (this i know best) for instance there is "dsh" (distributed shell), which is a rework of a part of the PSSP middleware introduced for the SP/2 (i can't remember when this platform was launched, probably somewhere in the beginning of the nineties).

When i install AIX systems i usually start the customization with establishing exchanged ssh-keys as a "chain of trust" with some central management system (usually my NIM-server) and then use this system to administrate the system further. Most of my work is done without directly logging on to the system but by developing and executing scripts, which use "dsh" (or even while-loops feeding some host-list into a "ssh"-command) to execute commands remotely.

So, to come back to my point "log in as normal user and 'sudo su' to root" is an advice of dubious quality IMHO. Yes, if your system is for private use or anything similar to this it is good, in a real data center it is rather less practicable.

bakunin

I think you've taken my position a little farther than I've meant it. I do login as root on occasion. I just don't allow root to login externally. That's what sudo's for -- it gives you the same thing in a less blunt, more careful way.
If you allow 'sudo su -' you might as well allow sudo to do other things since you have zero effective restrictions anyway. I have one sudo-enabled user that I use for administrative things. So you're left with the enormous hassle of 5 extra keystrokes per command.

Granted, I have made that particular user very difficult to get to via anything but ssh keys. The keys themselves are password protected, too. I login once in the morning, ssh-agent, and have access to my servers throughout the day.

Sometimes I'll push a job into root's cron table if I really need to run an awful lot of root commands.

Fair enough. If i understand you correctly this would mean to roll out a single command on my management station might look like this:

Code:

while read WORKHOST ; do
     ssh someuser@${WORKHOST} "sudo su - root -c command"
done < /path/to/hostlist

with someuser being allowed to "su" to root without being asked for a password.

If so: what is the gain of having someuser login and switch to root without further authorization to having root log on directly? It is clear that this just transfers the "risk" from one user to the other.

There is one conceivable point for doing it this way and this is: if a host is under constant attack from bots then these bots will most likely try only "root" because the name of this user account is known. One can use any other non-default name for the "sudo-root-user" and the bots will not even try this name.

This is a valid argument but it is a predicament probably only a very few select systems are in. In most corporate networks this sort of attack is already stopped at the networks entry point.

bakunin

I'm a fan of always logging in as a non-privileged user and then sudo -i to operate as the superuser. This is certainly true when the system is on a network, and most systems are on a network these days.

From a console login? Well, that depends on the physical security and the critical nature (importance) of the system.

Not without my password-protected key, they can't. Even if they steal it, it won't work for them without the password. ssh-agent is how I use that to automate.

This was not what i meant: you have some user-account, which is allowed to log on AND it is allowed to "sudo su -". You protect this account with a password, a key and whatever else. This protection amounts to some level of security (whatever "some" is, this is not my point). If you would log in as root directly and have the same amount of security - the same key strength, the same password strength and whatever else you use to protect your user account. My point is that it follows, that these measures would amount to the same amount of security as with the user. It is equally hard to crack a key or a password, regardless of this key (password) protecting the root-account or any other user-account.

bakunin

Ah, I see.

What this gets me is:
1) Nobody needs root's password.
2) You can't brute-force root over ssh, period.
3) There can be more than one account like this, for different people and purposes, and none of them need root's password or each others' passwords.
4) I can revoke root access at will with usermod without inconveniencing everyone.

So it's more for internal security than external, I suppose.