| Previous | Table of Contents | Next |
The root login is reserved for your administrators. The person who logs in as the root has the power to erase any file, restrict use by any person on the network, and quite literally to cause havoc among users. That’s the downside of the picture. Linux was designed to give the people having root access the tools to do their jobs better than in other environments.
Many proprietary operating systems have blockages established by the creators to avoid accidental damage to files and other operating factors on the system. The creators of UNIX and Linux took a different attitude toward the administrator. You’ll find tools that permit you to connect almost any computer device. You’ll find software that monitors the performance of the computer. You can create an endless array of software and adapt it to just about any business environment.
Also, you can force your users to do only specified things on the computer, or you can give them limited rights until they grow in their knowledge. The root user, the administrator, has the power to do these things.
NOTE: Because access to the root is so important, some companies restrict use to a select few.
Allowing access from a common modem, similar to those that people have at home, can permit someone to “crack” the system and destroy important data. As a result, many companies insist that the computer have elaborate security mechanisms, which can make these computers almost impossible to work with. Some companies put a dial-back option on the computer so that you must dial the computer and then wait for a return call before you can interact with the system.
Most of the time, a traditional UNIX/Linux approach is recommended. Make sure that all your user logins have passwords. Restrict the systems that can connect to your system. Keep permissions closed on sensitive files. Be careful of set UID bit programs (those that give the user who runs the program the permissions to run as another user). Most break-ins occur because someone left the door open.
NOTE: Ultimately, security is a problem with people rather than systems. You can’t allow passwords to be etched in the wall near a terminal or have DOS computers with root passwords embedded in communication programs.
Users should log out or use some kind of terminal lock program when they leave at the end of the day. Most UNIX systems have such a program that shuts down terminals left on beyond a prescribed length of time.
Security in defense firms is clearly understood. Companies that have highly sensitive products in the design cycle understand the need for security. But employees in a small distributor of plumbing parts may have a hard time understanding what everybody is so concerned about. Security in this example isn’t an issue until you can’t figure out who removed a file that included a key proposal.
Employees should have a quick lesson about the sensitivity of data on your computer. A business has a significant investment in the data on the computer. Loss of data can be a distraction or it can mean chaos. Employees who are unwilling to participate in securing a computer should understand that this can be cause for dismissal.
For an administrator, the task becomes apparent. If you’re the chief security officer for the network, how can you be sure that files and directories are adequately secured? Fortunately, there are many tools to help you, such as umask, cron, and Linux itself.
Permissions seem to be a significant source of worry for most administrators. New administrators typically tighten up permissions and then field calls from people saying they can’t gain access to a file they need or can’t execute a program on the system. After a while, these administrators loosen up the permissions so that anybody can do anything. The balancing act of securing the computer while permitting the proper people the tools to do their jobs is sometimes frustrating.
Security on a computer can require a little detective work. For example, look at the following:
# who -u root tty02 Jan 7 08:35 old Ofc #2 martha ttym1d Jan 7 13:20 . Payroll #1 ted ttyp0 Jan 7 08:36 8:25 Warehouse margo ttyp2 Jan 7 07:05 9:45 CEO Ofc root ttyp4 Jan 7 08:36 . Modem #1 # date Tue Jan 7 19:18:21 CST 1997
Suppose that you know that Martha left the office at 5 p.m. Has someone found her password, or did she leave the terminal on when she left? You can see that she logged in at 13:20 today. It’s now 19:18, and somebody is active on the system using her login. Do you dispatch security?
But what do you do if someone does break into your system? First, try to determine whether you really do have an intruder. Many times, what you notice may just be the result of human error. If you do have an intruder, you have several options. You need to decide whether any damage was done, and the extent of the damage. Do you prosecute those responsible if you can catch them? If so, you should start trying to gather and protect evidence.
You must decide how to go about securing your system and restoring any damage from your backups. Probably the most important thing of all is to document what you do. Start a log immediately. Sign and date any printouts showing evidence of intrusion; these may be useful as evidence. Your log may be invaluable in helping you figure out what you’ve done when you have to change or restore files.
Two other preventive measures that you should take are to make printouts of your basic system configuration files, such as /etc/fstab, and establish a site security policy. You must make sure that your users are aware of your site policy and that they’re reminded frequently.
Another area of concern is when an employee leaves the company. When an employee leaves, for whatever reason, personnel should contact the computer staff to retire the login.
With all the different security considerations, how much security is enough? Can you have too much? You may be surprised to learn that yes, you can have too much security. In general, if the cost of recovering from a security breach is less than the cost of security, you should reduce the security level for your systems. Note that these cost factors include much more than monetary costs. Among other things, you should take into consideration the content of your files, the amount of time and money that it will take to replace them, any lost productivity time that an attack would produce, and the effect that publicity of a computer security problem will have on your organization.
| Previous | Table of Contents | Next |