Don't shoot me...

[Alan Garner]

I have what may seem like a REALLY dumb question. I am 6 months into my *nix admin transition. As I was trying to explain to my supervisor that we should really look into beefing up our internal security, he asked "Why, our network is secure!" That when I realized that I really didn't know why...its just one of those things that you do!

As for my real reason for posting here, alot of documents, articles, and forums on the Internet suggest that root be prevented from remote login. Why? I can understand this if one were using older methodolgies such as rlogin, telnet, rsh...etc where the protocol sent the credentials in clear text but with ssh encrypting the connection, what's the issue?

These articles and such say that one should implement su or sudo instead of logging in directly but then I question myself. Isn't this the same thing...? What's the difference? This is where I get confused. Whether I log in directly as root using Putty, or I log in as another, less priveledged account and then sudo evey command I need to run, it still provides the same results, only I have extra steps.

I do grasp the concept of "accidentally" running commands as root and potentially destroying the system, but again, I can do that usung su and sudo.

Please don't attack me as I am just trying to fully under stand the concepts here. I come from the Windows side of things...ah, there's my problem! LOL.

Anyway, I would be very appreciative if someone could explain what the hubub is about letting root login remotely! Thanks!

[Steven E. Protter]

Shalom Alan,

When root logs on remotely using the older protocols, telnet, other than openssh, the root password is generally sent across the network in clear text. That means any user with simple tools can intercept the root password.

Which means if you do this, your network is NOT secure.

openssh, packaged under the name secure shell by HP is an exception. Both the authentication and data stream are encrypted which means eavesdroppers get nothing useful they can use. Password free access is easy to establish safely.

That in summary is the issue. root user is pwoerful and you don't want its password sent across the network in clear text. With proper security provisions and openssh, you don't have to.

SEP

[Jeff_Traigle]

Coming from a Windows world, you should be incredibly familiar with not relying on your network security to protect you from security threats. :) True story... back when I worked for an unnamed huge corporation in the late 1990s to early 2003ish, they had this naive notion that the intranet security didn't matter much because they had this awesome firewall stuff protecting them from the evils that lurked on the Internet. (The security model is usually described as "crunchy on the outside, gooey in the middle".) It took one hit from one of those nasty Windows worms (I think it was Blaster) to bring the entire corporation to its knees as far as Windows 2000 was concerned. Now, that story has more to do with patching than the types of security you mentioned in your query, but it serves the point of why you never rely on a single layer of security to protect you. Good security models always use multiple layers and provide accountability (which you lose when you let root login directly remotely, to answer your last question) and auditing at as many layers as possible. O'Reilly has a pretty good selection of security books which go into much greater details... Security Warrior comes to mind as one that covers a lot of territory. (It helped me quite a bit for a project I was working on a few years ago.)

[Tim Nelson]

Here is a good question for your boss.

If the network is secure then why should anyone have passwords ? Just as much protection if not more needs to be from the inside let alone form the outside world.

I believe the studies show there is a high number of issues/attacks ( like > 80% ) that come from the inside.

It would be pretty naive to use his current excuse and certainly would not hold up to any external audit.

Maybe he is testing you and wants you know why.

As far as the direct root access. Yes, disable using /etc/securetty file. This will only allow a direct root login from the system console ( at least for telnet ). You would then need to su to root. Many many many other options depending on how tight you want to get. Just do not get so tight you lock yourself and everyone out ( i guess it would be considered secure then if no-one can get on the system ;).

[Glenn S. Davidson]

Steven explained it pretty good.

I think what you are unable to explain is that a majority of the issues regarding server security are protecting you from the users of the server (i.e. employees). Many of the security features you are mentioning/asking about provide tracking within the server itself. Whether you have a breach from inside or outside these utilities (sudo) limit the capabilities of the user (legal or not) so that you can track down who is doing what and how things happened.

Sudo is not just another step. If set up correctly it allows incremental root usage and logging of individual commands and their arguments for specified users. It also allows users to run commands without having to know the root password (which su requires by default).

Steven also mentioned that under SSH (and sudo) it's easy to configure password free access.

Last thing:
It's always a concern when things change. People are resistant to it and will spend more time and energy fighting it than learning the new processes and as security goes up, flexibility goes down.

[Alan Garner]

I appreciate the replies but none of them really answers my question.

I understand turning off telnet, rsh, and rlogin (or other non-ssh protocols) as the credentials are sent in clear text and human readable by anyone who can capture packets. My question specifically refers to using ssh.

It seems maybe I am not getting my point accross so let me explain a bit more.

Consider the following scenarios. Using a ssh client such as putty, I...

1) login as user1, su to root, enter root password, run vipw.

or

2) login as user1, run sudo vipw.

or

3) login as root, run vipw.

All of these scenarios I presented above will produce the same end result...the vipw command being successfully run. Now, why is it that the first two are acceptable and the latter is frowned upon when option 2 & 3 are in effect identical!

I understand that using sudo could provide a measure of auditing and problem tracking should something go wrong. Beyond that, I do not see a difference!

The only answer I have been able to assertain is that disabling root access via ssh would prevent any remote access by root should a rogue user comprimise the root password utilizing some form of brute force attack or password cracking tool! However, looking at the scenarios above, should a sudo enabled user's password become comprimised, it poses the same threat!

I hope this helps clarify my issue a bit!

[Glenn S. Davidson]

I think that the biggest difference is tracking. Not for troubleshooting but for security and auditing. Most of the environments I have been in have come under strict auditing and need to have the ability to know who is logging in and running administrative commands. If you log in as root directly you have no idea who is really logging in. You can find out what 'they' are doing but the 'who' is going to be pretty hard to figure out. If you log in as your own user then the commands you run as sudo can be directly traced back to a specific user because commands can be logged. Using just 'su' you can only see who is switching to root to run commands but you cannot trace the specific commands back to a specific user. The shell history file will tell you what was run but not who or when the commands were run.

I think the big deal is really responsibility. I would not want to (and I have stood pretty strong on this) be responsible for a server that was wide open for anyone to log in as root and do whatever they want. If you are going to hold me responsible for the functionality of a server I need to know who is doing what so I can undo whatever got screwed up to get the server back to full operation.

[Bill Hassell]

> 1) login as user1, su to root, enter root password, run vipw.
>
> or
>
> 2) login as user1, run sudo vipw.
>
> or
>
> 3) login as root, run vipw.
>
> All of these scenarios I presented above will produce the same end result...the vipw command being successfully run.

Well, in scenario #1, you just gave away the root password to an inside hacker -- your system has been seriously compromised.

For scenario #2, user1 has 100% root access to everything and potentially every other computer on the network even though sudoers file limits trhe user to vipw.

And in scenario #3, the root password has been captured from your PC.

------------

So to explain how security is DEFINITELY NOT a network issue:

#1 the user ran su which was a simple script stored on /tmp by a hacker that captured the root password and said: sorry. user1's $PATH had /tmp in front of /usr/bin. How often do you check /etc/PATH and /etc/profile?

#2 sudoers said it was OK to run just the vipw program but user1 can escape the editor with :! and get a shell prompt -- and with a root shell, and do anything. And sudoers almost always has: ALL=(ALL) ALL which defeats the purpose of privilege separation. The other aspect is setting up publickey root access to all the other systems. Gain root access on one and the hacker now has passwordless access to all others. The network security is now meaningless.

#3 the user has had the root password as well as all the other logins to other systems including web pages, online banking and personal email all stored on an inline dongle in back of the PC where the keyboard plugs in. The janitorial service will collect the dongles at about 2am tomorrow and sell them for a bundle of cash.

I work in the banking industry now and root's password is constantly changed every day -- no one logs in as root. Specialized (compiled) programs enable trusted scripts. We have random security sweeps that look for everything from secure papers, tapes and even loose disk drives and thumb-drives. These are collected 24 hours a day and requires a 1st and 2nd level manager to return the material.

It's not often that break-ins are based on the Internet, external to large companies. Instead, the majority of security compromises are on the inside, almost always through social engineering techniques and/or blind use of contractors both for technology and also for janitor services. Proper security involves many layers and disciplines to be effective.

[dirk dierickx]

when you logon as root or use 'su' to gain root, it means you must know the root password. when using 'sudo' you can run as root, but you do not know the root password.

root must be protected at all costs, because it is the only weak spot on a unix system. (unless you run some advanced security package that is more fine grained like Solaris10 or SELinux).

sudo also has extensive logging, so in case something happens it is easy to trace back to who did make the mistake. if everybody logs in as root, you wont have an easy time finding that out.

you want to limit remote root loging because, once you get root the game is over. in fact root should be limited to only console login and no network access what so ever.

[Andrew Young_2]

Hi Alan

I think in terms of security the following rules should apply.

Firstly only administrators should have login access onto a unix server, most other users should connect at an application level.

Secondly if those admin users need to do any system administrator tasks the should use sudo or su -.

In this way to get admin access to the server 2 accounts need to be compromised. It just adds an extra level of security. Also is anyone wants to attempt to get into a server the obvious account to try would be root.

However as some others have stated here that extra bit of security is really there to keep the novice crackers away as there are many other ways to get access or get the information to allow access. Unfortunatley. But why make it easy for anyone.

Every small level of security you add makes it incrementally more difficult for anyone to compromise a server.

And as far as your supervisor is concerned (read stupidvisor perhaps?) the only truelly secure network is one with no hosts attached, everything else involves some element of trust somewhere.

Regards

Andrew Y

[Alan Garner]

Ok so here's what I have come to conclude...

Allowing root access requires that multiple people know the root password, allows unrestricted access should that password be comprimised, and provides little to no auditing of individual actions.

Using su is said to provide an added level of security but still requires the knowledge of the root password, still dangerous, and still provides little auditing.

Using sudo requires the user to be a bit more aware of the commands that are being run, provides additional logging and auditing of who ran what when, and can be granularly controlled. However, the logging can be easily circumvented by simply running another shell.

So in short, there is no magic answer to the root vs. su vs. sudo debate! Preventing root access is simply one step in the whole security approach. While similar risks are presented when allowing other users to su or sudo, it is still generally accepted as "safer" then allowing uncontrolled root access.

Whether I allow root access, require su or sudo, there still must be a level of trust...be it from fellow co-workers or in you perimeter security!

I will leave this open for a while and see what other responses I get. Thanks again for all your input!

[Geoff Wild]

If root can login remotely, then all it takes is just one of your servers - say a DNS server, that a hacker or malicious user compromises - and now they have full access to your entire infrastructure. THe other main reason - auditing - you need to know at any given moment, who became root.

You should spend some time on securityfocus.com

Some other links for you:

http://www.eecs.wsu.edu/~cs302/notes/security.html

http://www.cert.org/tech_tips/usc20_full.html

http://www.cpc.unc.edu/restools/datasecurity/unixlinux

http://www.sun.com/blueprints/0502/816-4816-10.pdf

http://www.faqs.org/rfcs/rfc2179.html

http://www.certconf.org/presentations/2000/CSGUnixChecklist.html

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B6849AA

And many...many...more...

Rgds...Geoff

[Steven E. Protter]

Shalom,

Any scenario that permits direct login with root from a PC can cause compromise of that system to release the root password.

pc's easily pick up spyware that includes keystroke copy and that can let your root password out the door easily.

One of the reasons on the two internet exposed servers, I maintain interactive root login is disabled.

If you add this option to sshd_config

PermitRootLogin without-password

This will only permit root login with pre-placed public keys.

Inside a trusted network where people don't have admin rights in their pc's I see no reason to implement this. It all depends on your level of paranoia.

You kind of whomped on me a bit for my first response, but that's valid too.

I'm not a big believer in disabline direct root login but it does improve security.

You can also simply disable root login and require people to log in with unpriviledged accounts and then su - root. This however disables password free public free access and generally that is bad because you want machines to be able to send files to each other and check each other.

SEP

[Court Campbell]

These would be my suggestions.

1. don't allow root login via ssh. I have varying reasons for doing this.

2. create a group and set the SU_ROOT_GROUP in /etc/default/security. This will only allow users in that group to su to root.

3. setup sudo. This will give users privileged access to only the commands you specify.

4. if you want to know more about what is happening on your system then setup hids.

[Doug O'Leary · Accepted solution]

Hey;

In case you haven't noticed yet, security arguments can get religious in nature.

The short answer for the reason for network security vs system security is the vast number of hacker incidents are internal - someone already inside your network doing things they shouldn't. Add to that, things like accidental or inadvertant changes, what not.

Network security is just one aspect of the security posture - system securit is another and physical security is a third. There is a whole branch of certifications for security that cover all of these things.

As for the direct root login: There's generally two reasons to prevent direct root login. The first is to control who logs in as root via a two step login process. The second is called repudiation. That basically means being able to point at a belly button and say "You did this as root on this date at this time".

To side-step for half a sec, there are 3 factors for authentication:

1. Something you know (password/passphrase)
2. Something you have (secure token)
3. Something you are (biometrics)

The more factors you employ, the more secure your system is. Passwords are single-factor authentication.

I generally agree that direct root login should be prevented if you're using passwords. Direct password oriented root access violates both reasons for disallowing direct root access. There is no way to be certain that the person with the root password is who he says he is. That's actually a weakness of *any* straight password based system.

Where I tend to disagree w/direct root login (get ready for the flame war :D) is if direct root login is provided via secure shell/public key authentication (pka). PKA is 2-factor authentication as it's something you have (private key) and something you know (passphrase to the private key).

There is no way to "accidentally" configure pka access. The benefits of using pka are very similar to what you get by allowing rsh access to root - but without the gross security concerns. If you're managing 100 or more systems, something like this tends to become a requirement rather than a nice to have thing.

The downside to pka is that it effectively moves the security control from the UNIX server to whatever system is housing your private key. If you're not using a passphrase, you might as well leave root open; if you leave your sytem unlocked, you might as well leave root open. If your private key system is vulnerable to attack, then your UNIX system is at risk.

As the paradigm says, the only secure system is one that's buried 50 feet underground in a concrete bunker that has no external network storage and it's own power supply, surrounded by well armed, well paid guards - and even then, the security is suspect.

UNIX security, probably more than any other aspect of UNIX system administration, is a balance of useability vs security and can be very complicated. It's very important to know and understand the impact of various configuration decisions. You may *think* you're secure, but the local hacker can prove otherwise.

HTH;

Doug O'Leary

[Alan Garner]

Steven - I did not intend on "whomping" anybody so my appologies.

Court - Thanks, I'll look into hids.

Doug - The most complete answer that matches what I have been looking for!

Thanks to all who contributed! I'm gonna put togetehr a business case and present it to the powers that be. If they don't like it then, well...anybody hiring?

Best regards,

Alan

[Keith Buck]

One thing I didn't see in reading through the suggestions in this thread was the following scenario:

Several folks share administrative responsibility for a given machine. One of them leaves the company (let's say under good terms). How do you manage his account if everyone always logged in as root? Do you change the root password and communicate that new root password to everyone? (Probably not a good idea)

If you use something like sudo or a role-based access control solution (HPSIM or HP-UX RBAC, for example), you can let the users login with their own account, and manage that account separately from "root". As far as whether Fred uses fred's password or has to type that and root's that depends on your environment and business. But this is one of several reasons that many security guides recommend restricting direct root access (in addition to the auditability mentioned already).

If you don't need to share the root password to get your job done, it's a lot easier to change the root password without affecting people, and to change the account status of an individual without affecting everyone.

Hope that answers your specific question.

-Keith