or example, a number of financial institutions seem predetermined to use NIS to manage large numbers of accounts across a multitude of systems. So what’s the problem with that? Anyone who issues the command ypcat passwd can gain access to the encrypted passwords for all users on the network, including administrators’ accounts and possibly the root account itself.

Generally, a quick review of that password file will turn up numerous development accounts. A number will have the username as the password, a large number will have the company’s acronym as the password, and—the intruder’s favorite—one or two will have no password at all. If the intruder isn’t lucky enough to find any accounts without passwords, he or she can always run them through a password cracker. Either John the Ripper, or the old favorite Crack, will crack bad passwords within 15 minutes to an hour, and the larger the user environment, the greater the chance of bad passwords.

Administrators should be using these tools on a regular basis, but none seem to be. Some systems I’ve come across have OS-level controls for password checking, but they aren’t being used, either. Given that the majority of machines use regular password authentication, password cracking is an easy means for an attacker to gain access to systems without using any fancy exploits—or even their infamous scripts.

Reduce Cross-Environment Access
What can be done? Initially, administrators should get rid of NIS. They might be able to use NIS+, but support across a heterogeneous Unix environment is spotty and will require some custom scripting. But in the end, it should prove no more painful.

For this scenario, I discuss how best to split the development and production areas. Administrators must carefully determine who in their environments need (and are given) access to both environments. They should ask themselves the following:

• Do they have separate administrator groups for development and production systems?
• If so, do any of them need access across environments?
• Do any other users need access to either environment?

In a clear-cut case, no developers should have access to production systems, and very few administrators should be allowed to work between the two environments. Production systems should consist of only applications and software that have been tried and tested in the development or staging environment. (Administrators whose environments actually work this way are a rarity in my experience.) The challenge is to devise a way to work close to this ideal, while allowing for the exceptions that most environments require. Step one is having the administrator answer the questions above. In general, fewer users should require access to systems in the development environment than systems in the production environment. The number of people who require administrator access should be smaller too. If your administrative group is large enough, responsibilities can be divided among smaller groups that administer each machine type.

Developer Pushback
As security conscious as it may be, developers generally aren’t thrilled with a policy that denies them access to production boxes. They often will push back, claiming tight security will make their jobs near impossible or will increase development time. It may make development difficult at first, but developers eventually will get used to it; with any new aspect to a system, a learning curve can be expected. The most important thing is that systems ultimately will be much less susceptible to exploitation.

Setting the security expectation early is the smoothest way to get developers on board, particularly at a startup. Bringing up the security concept late in the development process generally means delays. Since no one really has been thinking about security ramifications, the processes in place will need to be retrofitted. Trying to retrofit a solution becomes very costly in terms of both time and money. Also, most solutions should be able to grow as the environment grows. For both startups and established entities, the introduction of security concepts prior to the first (or yearly) security audit will make the audit much less painful.

Next, administrators will need to download a couple of tools: SSH Secure Shell and Sudo (superuser do). Administrators who aren’t familiar with SSH had better become familiar with it very quickly. I’ve yet to find it in an environment I’ve reviewed, but SSH should eventually replace Telnet for communication between all Unix boxes, as well as routers. The closest I have seen to such an environment is one where SSH was installed and used by the administrators but Telnet also was enabled and used (often by non-administrators).An SSH implementation should eliminate all unencrypted network logins, which will help protect the network from the various password-sniffing vulnerabilities, as well as protect the data going back and forth across the connection. SSH also can replace all of the r* services on Unix servers (not that unauthenticated rlogins should be allowed anyway), as well as FTP.

The real benefit of SSH, however, is its ability to either replace services such as rdist (a utility for distributing files across systems) or allow them to tunnel through itself. For the sake of demonstration, I describe how I take a very secure system and make it the central password server. Then, from this server, I will generate custom password (and shadow) files for the other systems and distribute user accounts as required to the systems to which the users need access.

A general security rule is to have unique passwords across every system. But following this rule generally isn’t practical when you’re talking about the administration of 15 or more servers. Good password selection is difficult enough, but when a user has to create more than one and may have to change it every 30 to 90 days, the quality and the uniqueness generally drop—dramatically.

Rather than get into a holy war over it, the administrator should assume that if he or she can’t find a way to use a one-time, token-based authentication system, users are going to need to reuse passwords across systems. It’s the only way for users to come up with decent passwords that they aren’t going to write on yellow Post-It notes and place next to their monitors. Thus, one solution is having them use different passwords across different types of systems (front-door web servers, back-end servers, database servers, mail servers, DNS servers, SSL servers, etc.). Given that often times these systems will be maintained by different groups of users, this often will follow existing segmentation. Next, rdist (as well as many other services) connections can be tunneled through SSH to distribute the password files to each of the servers. That way, administration can be done from a central server, user accounts are placed only on systems for which access is required (to a point, this can almost be a web-based application), and system security features such as shadowed password files are still in use. In addition, even if the administration server dies, user access to the machines should not be interrupted because the local password files are accurate.

However, these applications—as with all applications—have drawbacks. Constructing the proper password or authentication files for a heterogeneous environment has its difficulties. While BSDs, Linux, and Solaris variations are generally simple and very similar, HPUX and AIX variations will require a review of a number of main pages to refresh oneself with all of the fields. (Hopefully, the applications allow for the use of the Trusted Computing Base (TCB) on the HPUX servers.) This isn’t the easiest way for managing user-password changes either, since changes made locally on a server will not be propagated through the rest of the environment.

Sudo: The Best Available Option
Now that the accounts are distributed across systems, let’s look at Sudo. For a given environment, if someone gets enough pieces of the “root” puzzle (i.e., access to the users who can create accounts or change passwords, along with access to the users who can adjust the configuration files of the “root” distribution program), that person can acquire the equivalent of root access. So I refuse to give any credence to programs that claim to remove the “root” account. Thus, I am left with the best available option, and Sudo is a great tool in a number of ways. It is free, it has been ported to most systems, and it can be configured with a great deal of granularity.

Now, assume that I don’t allow direct logins to the root account from anyplace other than the console. I’m also in an environment that has more than one administrator. (Every environment should be this way, just in case of the “hit-by-bus” scenario.) How can the functions of the root user be shared among multiple administrators while logging the actions that each user performs on the system? How do I limit who has the ability to run programs as root? How do I limit who can switch users to root?

These tasks can’t all be done through system configurations on every operating system I have. However, I can add in functionality for the operations group so they can perform some of the more mundane tasks or error-checking routines on the production servers, and the administrators don’t need to be called or paged with the dreaded 4 a.m. wakeup call.

With Sudo, the administrator can grant users the ability to run commands (typically as root) from an extremely granular single command or to a range as broad as any command on the system. One of its most important benefits is the increased logging. The standard practice is SU-ing to root and then executing a command or commands, where only the action of the SU may be logged. Sudo, on the other hand, logs each command and the user who ran it. It also helps prevent the occasional mistake that a user who is always logged in as root makes, like accidentally running commands or deleting files because they forget they are logged in as root.

By using the granular ability of Sudo, I can grant user-level access to users of other machine groups so that they can test connectivity between servers on the network, and I can grant users who administer those machines access to administrative commands. Access to these other accounts should be used only as a troubleshooting tool, not as a replacement for a realistic development environment. Proper testing should be taking place prior to rollouts to production.

As I alluded to earlier, Sudo is simply a tool, not an end-all, be-all security tool. If administrators get used to using it, a number of stupid mistakes will be prevented. But this won’t prevent access to root or keep the server from buffer overflows. It will help administrators limit and log general system activity as well as determine who did what when they troubleshoot a system failure. And they can distribute the Sudo configuration files the same way that I distributed the password files.