|
UNIX Hints & Hacks |
 |
||||||||||||||||||||||||||
|
Chapter 3: Security |
|
||||||||||||||||||||||||||
|
|
The best security administrators are usually current or former UNIX administrators. UNIX administrators need to be paranoid by nature, because few, if any, virus protection programs are available. The only proactive steps you can take are to continuously monitor the system, stay paranoid, and keep up-to-date with the latest security advisories.
It is often said that UNIX administrators get the blame if a system is compromised. Check with your management and verify what exactly you are responsible for if a system is compromised. Get it in writing if possible. Some corporations risk hundreds of thousands of dollars. If your resources are stretched thin, management is aware that there is a problem, and they are not working to rectify the situation, you should not be held responsible. The manager is often responsible for everything and might try to pass the blame to you if an intruder gets into a system. This, of course, all depends on each individual environment. If you work in a high security area, you might have to take full responsibility for the systems; it comes with the territory.
Monitoring often comes at a price. Keeping an eye on system files that are modified and removed takes up processing time and can slow systems down. It also takes up a lot of disk space and can be boring work, but it's work that has to be finished.
Learning the system, the files, and the files' permissions comes in time. An intuition of what files belong and don't belong in various directories becomes second nature.
System administrators need to stay up on all the latest advisories and vulnerabilities taking place in the security industry. The CERT Coordination Center (CERT/CC), at http://www.cert.org, maintains a listing of all current and old security advisories for UNIX. CERT/CC is an excellent contact for security intrusion resources and works with various government agencies. If your systems are compromised, CERT/CC can help you determine where to go, what the next step is, and how to get to the right people.
If multiple admins need root, here is one way to control and regulate root access.
Flavors: All
As you know, root access is the basis of all security on a UNIX system. After root is compromised, the system is open for the taking by hackers. The only other concern to watch out for is the user who thinks he knows what he's doing.
There comes a time when multiple admins, vendors, or dangerous users request root on the same system. Although one or two might really need it, others within this group or a department can usually justify having it.
Yes, I know, how could I give root to a user and even give root privileges to vendors? Unfortunately, not everyone can have the perfect UNIX environment. Sometimes users and even vendors get to have root access. A large-scale computing environment in which certain types of users--such as programmers, DBAs, and vendors--work in the office alongside UNIX administrators often contains users with some type of root access. With this method, you can at least track their sessions.
So why not set up one of those root access control programs, such as sudo? For those that don't know, sudo allows specific user accounts to run certain predefined executable files with full root permissions and access. Users always find a reason for not using these programs:
You know that the more people who share a single password on a system, the less secure the password is. So provide each administrator with her own root account. Here's how it works. In the password file, entries similar to these are made:
root:NqM5kgsU0o./6:0:0:root:/root:/bin/tcsh root-kw:4S55m/bx1PNLY:0:0:root for Kirk W.:/root:/bin/tcsh root-jd:4tK8yr/3.UWtI:0:0:root for John D.:/root:/bin/tcsh root-gr:WgDvjlaLlsgQA:0:0:root for Gloria R.:/root:/bin/tcsh
Notice that there are four root entries, each having the UID ( 0) and GID ( 0) of root. Because the UID and GID of each entry is the same as the account root, they all inherit the same access, permissions, and powers of being a superuser with root access.
The first account in the password file, root is reserved for the primary UNIX administrators who work on the system. You should limit the account to a strict set of circumstances that you always enforce if this is to succeed. Some instances of using this root account would be
The additional root accounts are designated by the word root, a dash, and the initials of the administrator, user, vendor, or person who needs root level permissions.
When the user logs in to a system with an account named root-xx, the accounting immediately logs the entry into the /var/adm/wtmp file for the last logs. If you stumble on some weird oddities within a system, you can find out who was last in with root privileges.
These root accounts should be used for all other superuser access to the system. Use these accounts to change permissions, mount filesystems, run fsck, or build device files.
The goal is keep root as secure as possible. This is one way to delegate root and track those who use it.
On more than one occasion, phone calls open with, "Did somebody do something to my computer?" Then you check the last logs only to find that a programmer was in the system as root prior to the user. In the end, there is usually an apologetic programmer who loaded some software or patches or started a process that inadvertently spawned massive I/O operations or ate up all the CPU time.
Man pages:
passwd(4)
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||
|
Chapter 3: Security |
|
||||||||||||||||||||||||||
|
|
© Copyright Macmillan USA. All rights reserved.
Previous
Section