CHAPTER 42. Basic Security Measures Every Network Administrator Needs to Know

SOME OF THE MAIN TOPICS IN THIS CHAPTER ARE

---

Policies and Procedures 810

Physical Security Measures 816

The Two Sides of Security 817

System Daemons and Services 822

Removing Dead Wood 823

Delegating Authority 823

Don’t Forget About Firewalls 825

Keeping a network secure is a time-consuming process that requires a lot of attention to detail. Similar to troubleshooting faulty equipment, maintaining network security is also a time-consuming practice that involves the following:

Detection of a security breach or network intrusion

Finding the cause of a security breach

Finding the method of an intrusion

Educating users about security on a continual basis

This chapter examines security from two different angles: first, preventive measures that can be used to help keep problems from occurring in the first place, and second, tools and techniques to discover these kinds of problems.

Policies and Procedures

To have security practices that make sense, you must first define—for yourself and the users of the network resources—a security policy that spells out exactly what can and cannot be done on the network. Intruders who might penetrate the network and compromise data or programs do so in many ways. One of those is to exploit “friendly users” who are on the network. Referred to as social engineering, this is perhaps one of the most overlooked but most often used method for getting access to a network. Most employees who simply use a desktop computer for word processing and other office activities are especially prone to this kind of security breach.

A good security policy that is enforced—in some cases through means of technological enforcement—can go a long way toward keeping naive users from disclosing information to those who might do harm to your network. If you don’t think your users are vulnerable, just ask someone to call up and say they’re calling from the help desk and need to know the user’s password. You’d be surprised how many times this tactic will succeed.

At the same time, you also should establish procedures to follow for routine tasks that are performed on a periodic basis, such as backups, restores, creating user accounts, and the like. When a task is described by a procedure that must be followed, there is less of a chance that something out of the ordinary will be done that can compromise security.

Depending on your site, there are several documents you can use to make users aware of the policies in place for computer and network security. Typically, the human resources department is responsible for having new employees review documents and having them sign the documents to show that they have read and understood them. Documents you might find useful for your site include the following:

Network connection policy

Acceptable use statement

Usage guidelines

Escalation procedures

Network Connection Policy

This type of document should define the type of system that can be connected to the network. It should set forth the security requirements, such as operating-system features to be used, and a person responsible for approving the attachment of new devices to the network. When configuring a new computer, a switch, or even a router, you should have explicit guidelines as to what is permissible and what is not. For firewalls (see Chapter 45, “Firewalls”), you should have a separate network connection policy that dictates what type of network traffic is allowed through the firewall, in both directions. If allowing users to connect using a Virtual Private Network (VPN), you should also have specific documents detailing how the laptop or other computers they use are configured. Allowing someone to work from home using their own computer is about the worst decision you can make. If the computer is used for personal as well as business work, you open yourself up to all sorts of programs that can infiltrate the computer and attempt to compromise your network, whether or not you use a VPN link.

If the business unit of your company (and not the IT department) decides that certain remote work is confidential, a policy should be put in place that requires a separate computer (such as a laptop, to include mobile users) to be used. By using a company-configured laptop, and not allowing users to make use of the laptop for personal access to the Internet, and disallowing a configuration change, you can make your network more secure. Just keep in mind that if the user is entering your network with his own computer, you will probably have little say over what is downloaded. By giving the user a company computer, and preventing (through a company policy) the use of the computer for personal usage, you can further protect your network.

The use of security programs, such as virus monitoring software, should always be required in today’s Internet-centric environment. Any procedures that must be used to obtain a computer account, along with the types of rights and privileges that can be granted to an account, also should be documented here, as well as what network addresses can be used and how they are controlled. Finally, you should explicitly set forth in this document that no connections are to be made to the network without following the procedures in this document, and without notifications made to the proper persons.

It cannot be emphasized enough that you have strict guidelines on how your computers are configured and that users must obtain permission through a written request for any deviances from the established policy. If a program is not supported by your central help desk, it should not be allowed unless a business requirement makes it a necessity. When that becomes the case, you should add the program to your allowable network connection policy documents and educate the help-desk staff on its use. In no situation should you allow users to download software from the Internet and install it on their work computers, on computers that are used in a mobile environment, or on home computers that are used to connect to your corporate environment.

Acceptable Use Statement and Usage Guidelines

A computer is a flexible device. It can be used for many things beyond the tasks that are needed by the ordinary worker during a normal workday. Although some might be concerned with the time that can be lost due to a user accessing a computer for non–work-related tasks, there are far more important factors to consider.

As mentioned in the preceding section, one of the most important things you should include is an acceptable use statement. This should state that all computer programs are to be supplied by the company and that unauthorized programs, such as those brought from home, are not to be used on the computer or network. Software piracy is not a victimless crime, as many people seem to think. It is a crime that is punishable by stiff fines and jail sentences. It is important that you make sure that users understand this and that you protect your company from possible litigation by showing that you have made an effort to prevent unauthorized programs from being placed on computers at the site.

Piracy is only half the issue when it comes to unauthorized programs. Computer viruses can easily make their way from one computer to another through floppy disks or by being downloaded from the Internet. Unfortunately, it is usually only after more than one system has become infected that a virus is found or reported. If all software that is used on the company network is first examined, approved, and distributed by a central source, you will have better control over this problem.

Of course, you also should state that users cannot make copies of software or data that is owned by the company and take it home or otherwise use it in an unauthorized manner.

In this statement, point out to users that they are required to report any suspicious activity or misuse of network resources. They also should be made responsible for taking necessary measures for protecting data and programs within their scope. This includes not leaving a workstation logged in when they are away from it for extended periods—they should use a password-locked screen saver when away from the computer. Another avenue of infiltration is leaving reports or other output containing sensitive information lying around, and the like. Just because you trust one employee does not mean you trust all employees. For example, if a printout of payroll information is left lying around, do you really think that someone is not going to look at it? If you do not put the rules in a policy statement, users might not realize that these things are a problem.

If dial-up access is granted to users, they should certainly understand that they cannot give information used for this access to anyone else, either inside or outside the company. Many times it has been shown that hackers penetrated a network not through repetitive password cracking techniques, but simply because a user left a password lying around or used one that was so obvious that it could not be considered secure.

All, and I mean all, access to your network should be done through a VPN or a dial-up mechanism that uses a firewall. Although your network policies may absolutely prohibit employees from using company computers for home work (or for mobile users on the road), I can guarantee that you will never be able to enforce this policy. Users will check their own personal email, read the latest news site, and, at worst, download software that may seem innocent, such as programs to play back MP3 files, or others. These things should not be tolerated in a secure network environment. A firewall can only do so much.

Indeed, there is an application on the Internet that can make use of “unused” fields in the IP packet to send one or more characters at a time using otherwise normal IP packets that your firewall will let through. When you consider that several thousand IP packets can be used in a single transmission, you’ll see that any hacker intercepting these can gain a lot of information from someone inside your company who appears to be a model employee.

The things you can put into an acceptable use policy are extensive. You must examine the specific types of resources you are trying to protect and think up ways to include them in the statement. Some other items you might want to consider are listed here:

Harassment of other users. What might seem like harmless horseplay in a typical office environment can constitute harassment when it’s done over a long period.

Threats. Statements that can be construed as an intention to perform some kind of harmful act should always be treated with the utmost importance and severity.

Removal of hardware (or software) from the premises without written authorization. This includes such things as authorization codes used to activate copies of software that is downloadable from the Internet, as well as copied software. You should not provide “CD burners” for employees who do not have an absolute need for them. Your typical backup procedures for networked disk drive share should be enough to ensure that data is not lost.

Using company email for personal use. This may seem to be a small matter, but as recent events have shown, just opening an attachment to an email can launch a virus on a computer. In addition, the content of a person’s email can sometimes be offensive, especially if the user has gotten onto a “spam” list. Lastly, do you want to pay employees to spend an hour or so each day reviewing their own personal email?

Bringing hardware into the premises without authorization, such as laptop computers. This is a policy that especially should be applied to vendors and contractors. If they need to perform functions (such as software installation or troubleshooting), then you should, if possible, provide the computer access they need, and be careful to supervise their access.

Attempting to access data not relevant to the user’s job, sometimes referred to as “probing” the network. This is, in my opinion, an offense that you should consider as a reason for firing an employee. There is never a need to go exploring the network. If the user wants to know where data or applications are stored, they should discuss it with management or your help desk.

Employees

Any document that outlines guidelines for using the network should point out to employees that they are to behave ethically on the network. Help-desk personnel, for example, often must access data owned by another person when helping them with a problem. Disclosing information to a third party that is obtained during this type of work is unethical. Administrators and operations personnel often have elevated rights and privileges on the workstations and servers that are distributed throughout the network. They should be made to understand that these privileges include a responsibility to professionally carry out their work without causing problems.

One of the main problems I’ve encountered with help-desk employees is that they are paid very little compared to others who manage the network. Yet they are a very vulnerable link in the chain. Only constant training and discussions about security can solve this problem because most corporations view the help desk as a minor department, where turnover is frequent because most employees here learn enough to go on to higher-paying jobs.

Vendors and Outside Connections

Another area often overlooked is when outside persons are allowed to access the network. If you have contractors who are brought in to do work that cannot be done by in-house persons, be sure that you have a usage guidelines document for them to review and sign. It should specifically include the fact that information on the network is of a proprietary nature and cannot be disclosed to any outside party, or to any employee in the company who does not have a need to know.

Additionally, the policy document should state that the contractor cannot discuss with others the type of information to which they have access. A little information can go a long way when given to the wrong person.

When hardware repair needs to be done, it is sometimes done by a third-party maintenance organization, or perhaps by the vendor who manufactures the equipment. Diagnosing some problems may require that the repairman have access to a logon account. If you maintain a user account just for this purpose, be sure that it is one that can be enabled and disabled so that it is available only when it is needed. For example, the OpenVMS operating system has, by default, a FIELD account that is meant to be used by field service when it needs access to the computer. This account is disabled when it is created and must be enabled by the administrator before it can be used. Because OpenVMS is a widely used operating system, there are a lot of hackers who are aware of this account and also know that many times you will set an easy password for it. Don’t make the mistake of leaving this kind of back door open to your network. Disable or remove accounts such as these when they are not needed.

Escalation Procedures

Having a plan of action that should be followed in response to a specific event is a good idea. There should be a specific person or persons in the company who are designated to be responsible for and investigate matters relating to security. A document that sets forth the procedures to be followed for particular security violations will also show users that security is important for the network and that actions will be taken.

A document covering escalation procedures should indicate the kinds of things that are considered a security breach. These can include the following:

Theft of hardware or software

Password discovery or disclosure

Improper disposal of media, including tapes, floppy disks, and printed reports

Sharing of logon accounts or disclosure of usernames and passwords

Probing the network to look where one is not authorized

Interfering with another user’s data or account

Suspected network break-in from outside sources

Computer viruses

Physical access violations

Some of these probably seem very obvious when you look at them. To think that you will know how to handle these kinds of problems without a written procedure, though, is a little naive. For example, it is very common for users to allow others to use their account. It’s a lot simpler to let another employee use your workstation, when theirs is out of service, than it is to get the appropriate permissions from upper-level management. However, it often happens that when you give someone a password to use on one occasion, it also gets used on another.

When you suspect that the network has been infiltrated from an outside source, what do you do? Shut down the routers? Change all the passwords? Think about this ahead of time and document a list of steps to follow. These steps should include methods used to determine the source of the breakin, as well as procedures to be followed to punish the intruder and reassert ownership of any pilfered information. For example, if information that is confidential has been compromised, what steps do you take to notify the person to whom the information relates? Are there legal matters you need to be aware of that pertain to the data that resides on your network?

Perhaps one of the hardest things a manager has to do is to fire an employee. When someone leaves the company voluntarily and is on friendly terms with management, it is a simple matter to deactivate the user’s account and be sure that all access doors are closed. When an unfriendly termination happens, though, you need to have in place steps to follow to be sure you are aware of all access methods that were available to the unfriendly employee. In the case of an employee who is terminated for actions that caused deliberate damage to the network, how do you determine whether any other “time bombs” have been planted? What steps do you take to isolate the resources that were available to this employee until further analysis can be done? Do you need to change passwords on accounts other than the user’s—for example, any test accounts or local system accounts to which the user may have had access?

As you can see, network security has far-reaching implications. Knowing what to do in the event of a specific security event will make things easier for you when they happen.

What a Security Policy Should Include

When writing a security policy, you should first perform an inventory of the resources you want to protect. Identify the users who need to access each resource, and determine the most likely place a threat to the resource might come from. With this information, you then can begin to construct a security policy that users will have to follow.

The security policy should not be something that is simply generally understood by everyone. It should be an actual written document. To remind users about the importance of security, you might want to post copies of it around the office so that they will see it on a regular basis.

A good security policy will be composed of several elements, including these:

Risk assessment—What are you trying to protect and from whom? Identify your network assets and possible sources of problems.

Responsibilities—Describe who in the company is responsible for handling specific matters relating to security. This can include who is authorized to approve a new user account up to items such as who will conduct investigations into security breaches.

Proper use of network resources—State in the policy that users are not to misuse information, use the network for personal use, or intentionally cause damage to the network or information that resides on it.

Legal ramifications—Be sure to get advice from the proper sources about any legal matters that apply to the information you store or generate on your network. Include statements to this effect in the security policy documents.

Procedures to remedy security problems—State what procedures will be followed when a security event occurs and what actions will be taken against those who perpetrate them.

Request for Comments (RFC) 1244 (“Site Security Handbook”) is a good document to read before designing a security policy. This RFC gives a list of resources found in most networks that are vulnerable to potential security threats. You can download this RFC, along with others, from the Web site www.rfc-editor.org/. These are the five classes of vulnerability vectors:

Hardware—This includes workstations and servers, printers, disk drives, network wiring, and disk drives. This also includes internetworking devices such as bridges, routers, and switches.

Software—Every piece of software you run on any computer in the network is a potential security problem. This includes programs purchased from outside vendors and software created in-house by your own programming staff. Operating systems frequently have to be patched as new bugs are discovered that give an intruder an easy way to infiltrate.

Data—The most important asset on your network is probably the data that is generated or used by your business. You can replace software programs and operating systems. When important data, such as customer lists, sales information, or proprietary trade secrets, is compromised, this can have a significant impact on business.

People—Users, operators, and anyone else who interacts with your network or any device attached to it is a potential security risk.

Paperwork—Often overlooked by many, this is a very valuable resource to hackers. Passwords are written down. Reports are generated that have confidential information contained in them. Often this resource is simply thrown in a dumpster when it is no longer needed. A better approach is to shred or otherwise make it unusable before getting rid of it.

A good security policy that is understood by users will go a long way toward preventing some of the problems you can potentially encounter. Make it a point to review the policy with users periodically, such as at quarterly meetings, and be sure that users understand the responsibilities that go along with having access to the company network.

Physical Security Measures

Preventing unauthorized access to resources means that you must first prevent unauthorized access to the physical components that make up the network. This includes user workstations, servers, network cables and devices, and so on. After the network connection leaves your physical area, such as when you connect to an outside Internet provider, you lose control over the physical aspects of the network. At that point, you must rely on other techniques, such as encryption or tunneling, to maintain security. However, the equipment over which you have control should be closely monitored to ensure that no one is tampering with anything in a manner that might serve to defeat the security policy in effect at your site.

Locking the Door

As silly as it might seem, the simple door lock is an often-overlooked security device. You wouldn’t leave your front door at home unlocked all the time, would you? The servers in your network that hold valuable or sensitive data should not be sitting out on a desktop or in an unlocked room where anyone can access them. Routers, hubs, switches, and other devices should be similarly protected. Wiring closets and computer rooms should have a lock on them or be protected by some sort of monitoring on a 24-hour basis. If you have a round-the-clock operations staff, you might not need to lock the computer room. But if that staff consists of only one person during any particular period, get a lock for the door! Ideally, access to these secure areas will be tracked and logged, such as through employee badge readers. With very sensitive systems, you may even want to go as far as securing physical access through biometric authorization systems. Biometric systems, though still in their infancy, can help ensure that someone cannot gain access to a secure area simply by borrowing or stealing a physical token.

Backup media, such as tapes or writable CDs, should be treated the same as live data. Don’t back up a server or your own personal workstation and then leave the tape cartridge or CD lying on the desk or in an unlocked drawer.

Uninterruptible Power Supply (UPS)

Keeping data secure can mean keeping it out of the hands of those who are not permitted to view it. It also can mean keeping the data safe from corruption. As more and more business-critical information is being committed to electronic form, it is important to take steps to be sure that it is not unintentionally compromised. A good UPS will pay for itself the first time you have to spend days reconstructing a database or reinstalling programs that become unusable due to a power outage or another problem of this sort.

Most computer operating systems have features that will work with a UPS so that the UPS can perform an orderly shutdown when it detects that power has been lost. If you are using a battery-backup UPS that has only a limited supply of power, an orderly shutdown can save a lot of problems when compared to a system crash.

UPS devices are covered in more detail in Chapter 5, “Protecting the Network: Preventative Maintenance Techniques.”

Disposing of Hardware and Media in a Secure Manner

When you upgrade your network and bring in new workstations or servers, it is a generous thing to give employees, or an organization such as a school, your old equipment if it is still usable. However, you should establish a policy which dictates that all hard disks are to be erased and, when appropriate, a legal copy of the operating system reinstalled on it. If you leave important information on a computer you give away, don’t be surprised when you see it again.

There is also the legal aspect to this. If you give away an old computer system, do you have the legal right to keep the software packages and install them on a new system? Probably not, unless you have a site license or another license that allows you to do so. For that reason, do not give away a computer that has applications installed on it unless you intend to give away the software packages also.

Disposing of used floppy disks, backup tapes, and tape cartridges also poses a potential security threat. It is better to destroy these information carriers than to give them away without being absolutely sure that you have purged them of any recoverable information. A bulk magnetic eraser can be a good security tool to use before disposing of this kind of stuff.

The Two Sides of Security

Locking the computer-room door is a preventive measure intended to keep out those who have no business being there. Preventive measures should be taken for software access mechanisms also. However, no matter how good you are at putting into place the access control mechanisms to protect resources, there is always going to be someone who will try, and possibly succeed, in breaking through. For this reason, you also must be able to keep audit trails of events on the network so that you can determine whether someone is trying to break your security, or whether indeed they have done so.

Before the Fact: Controlling Access

Controlling access to the network is done by several common mechanisms:

User accounts and passwords

Physical identifiers

Resource protections

In many operating systems, the concept of a resource owner is important in this scheme. For example, OpenVMS and Windows 2000/Server 2003/XP keep track of the user who creates a resource, such as a file. That owner is able to change the protections applied to the file and can grant others the permissions needed to use the file. To a lesser degree, the same can be said for Unix/Linux operating systems.

Identifying Users

In a homogeneous network in which only one user account and password is required for access to permitted resources throughout the network, system management is not usually a complicated matter. Windows 2000/XP and Server 2003 allow for the creation of areas of control, called domains, that operate as security boundaries. Users in a domain can be granted access to resources on any computer, either server or workstation, that the network administrator wants to give them. In addition, trust relationships can be established between domains when administrators cooperate, making it possible for the user to still use only one username and password to connect to resources throughout the network. From Windows 2000 and more recent Windows versions, group policies can be used to further control access to important resources.

Novell NetWare provides this functionality by giving the user a logon to the network that is controlled by the Novell Directory Services. Each user is represented in the directory by a User object, the properties of which specify information about passwords and connections.

The Unix operating system does not use the concept of a domain. Instead, each Unix host maintains a password file that stores information about each user, including an encrypted password. To access resources on other network hosts, the Unix user must either log on when accessing the computer or use a proxy mechanism. TCP/IP utilities such as FTP and Telnet often send user passwords across the network in clear-text format and are easy targets for interception.

The Unix remote utilities, usually called r-commands because they all start with the letter r, are used to perform ordinary network functions such as copying or printing files or logging in to a remote system. This is very useful in the network environment in which a user performs functions on many different machines. These utilities are not necessarily good when looked at from a security standpoint, however. Although the user must have a valid user account on the remote hosts on which these commands execute, the user does not have to provide the password.

Instead, an entry in the /etc/hosts.equiv file or the .rhosts file on a remote computer is what determines access. The remote machine trusts the computer on which the user executes an r-command if it can find an entry in either of these files for it. Each entry in the /etc/hosts.equiv file contains a hostname and a username, to identify users and the hosts that are allowed to execute these commands without providing a password. The assumption is that if you have logged in to the remote host, you have already been authenticated. The .rhosts file works in a similar manner but resides in a user’s home directory. The remote users entered in this file can perform functions based on the account associated with that user.

Although this sounds a lot like the Windows NT/2000/Server 2003/XP trust mechanism, it is not. It is quite easy to impersonate a remote node and gain entry into a Unix/Linux system by using the r-commands.

Resource Protections

After a user has been authenticated by the operating system, the next step to access a resource is for a check to be done to see whether the resource has any access controls placed on it. Typically, an operating system will grant access to a resource, such as a file, by granting users the right to do the following:

Read the file

Write to the file

Execute the file

Take ownership of the file

Delete the file

These concepts also can be extended to resources such as printers and modems. When granting these rights, most operating systems also enable you to specify which rights are applied to users or groups of users. For example, Windows NT enables you to group users into local or global groups. When you set the access controls on a file, you can specify the access rights by group. Using this method, one group of ordinary users might be able to read a file, while a group of users that manages the file might be granted read and write access, as well as delete access to the file. To prevent programs from being run by unauthorized users, the execute right can be granted or denied to a user or a group of users.

It is important to understand the features of your operating system that pertain to granting rights or permissions. Rights generally enable a user to perform an action. Permissions are placed on resources and define who can access and what kind of access can be made of a resource.

For more information on user rights and permissions, and on how they are implemented by different operating systems, see Chapter 39, “Rights and Permissions.”

After the Fact: Auditing Use

As you may be aware, there are auditing tools you can use to keep track of resource use, both attempted and successful logon attempts. Here it is important only to note that it is not enough to organize users into groups and grant them resource permissions throughout the network.

You can learn more about monitoring successful as well as failed logon attempts by reading Chapter 43, “Auditing and Other Monitoring Measures.”

There are several reasons for this. A large user base, combined with multiple servers that hold valuable resources, makes it difficult at times for an administrator who is not familiar with the information resources provided by a specific server to understand the permissions needed. For example, a new user in the accounting department might or might not need access to accounts receivable files or accounts payable files. They might need access to one or the other or maybe both files. A manager in that department would probably be the likely person to make the decision about what files the user should be able to access.

However, if the user is placed into a group, which is generally done to make administration easier, compromises sometimes happen, and the user might be granted access through the group to resources that they do not need to access.

Another reason is that sometimes mistakes are made. It is a fact of life that no one is perfect and that no system for allocating resources is going to get it right 100% of the time. When users are granted the capability to read a file, you can be sure, if the data contained in it is interesting enough, that they will do so.

Indeed, even if a user does not have appropriate access rights to a file, sometimes the user will try to get at interesting information anyway.

For these reasons, a good operating system provides auditing controls that enable you to look back after a security breach to try to determine who did what and where they did it. Unix (and its variants, such as Linux), Windows NT/2000/Server 2003, and Novell all provide features that enable you to record both successful and failed attempts to access resources. They all do it in different ways, and many of these auditing and security features are not enabled out-of-the-box; so if you have multiple operating systems on the network, it will be important that you understand each of them so that you can best enable and use these capabilities.

Passwords

It might not seem like an important thing to mention at this point, but you need to enforce a policy that makes users choose good passwords. And when you do that, you must decide what makes a good password for your environment. Simply put, a good password is one that is hard to guess. When you consider that a standard password-cracking technique used by hackers is to simply try every word in a dictionary, you can begin to understand that luck doesn’t have a lot to do with penetrating a network. It comes mostly from lax security that allows doors that are easy to open.

Enforcing Good Passwords

When deciding how passwords are to be constructed, there are a few guidelines you can follow:

Use more than one word. Multiple words “glued” together make a pattern of characters that is much harder for a simple password-cracking program to guess. Don’t use words that naturally go together. For example, Atlantabraves is not a good choice; Atlantayoko is a better choice. Never use a name of a celebrity or a popular institution.

Use nonalphabetic characters somewhere in the password. This can be numeric characters or punctuation characters, provided that the operating system you use will permit them.

In Unix and Windows NT/2000/Server 2003 Server editions as well as Windows XP, passwords are case sensitive. If you use both upper- and lowercase characters in a password, you can confound many password-guessing applications. Do not, however, substitute numeric characters that resemble alphabetic characters. One of the easiest things a passwordhacker application can do is to substitute the letter “O” for zero. Don’t fall for that one!

Don’t make passwords too difficult to memorize. The last thing you want is to have frustrated users writing down passwords so that they will be able to remember them. If you find this happening, it’s time to re-educate the employee. There are many methods in use today that can be used to provide “one password” for all applications on the network. You should investigate these types of applications and, if appropriate for your network, justify the cost versus the cost of a network intrusion. Many of these systems involve smart cards and PIN numbers. Again, although this may be an expensive up-front cost, justify it by the value of your data.

Use password history restrictions if the operating system permits it. This means that the operating system keeps track of a limited number of passwords that the user has previously used and will not allow them to be reused within a certain time frame. A common practice is to change your password when forced to do so and then to change it back to a value that you like and can easily remember.

Be sure that you do not create user accounts and assign them a password that never gets changed by the user. Most operating systems will allow you to set a password to be expired on its first use so that when a new user logs in the first time, he will be required to change his password.

Sometimes it is important to have a password that makes no sense whatsoever. In a highly secure environment this can make sense, in that you want something that is hard to guess. However, remember that when something is difficult to remember it usually gets written down somewhere, which can defeat the purpose of a password altogether. Unix has a command, passwd, that can be used to computer-generate a password for a user. For example, the command

passwd username

displays a list of potential passwords that are generally difficult to guess. The user can select one from this list to use if he is having a difficult time thinking one up. The only problem with this method is in getting the user to memorize the password.

Password Policies

No user account, including one used by an administrator (or root for the Unix/Linux community), should ever be allowed to keep the same password for an extended period. A good idea for passwords is to require that they be changed every 30–60 days, depending on the level of security you need at your site. You also should enforce a minimum length for passwords. Most operating systems will allow you to specify this value so that users cannot change their password to one that is shorter than the size you require.

On Unix systems, you can set the password minimum length by specifying it in a field in the file /etc/default/passwd.

On Novell NetWare servers, you can enforce a minimum password length by modifying the object properties of the template object used to create a user account, or by modifying the properties of an individual user object for a particular user.

Depending on the particular operating system, you can enforce other restrictions on passwords or user accounts to enhance security on the network. Some of the capabilities you might find include these:

Password expirations—A password should not be used indefinitely.

Password history lists—This feature prevents a password from being reused within a specified period.

Account lockouts—When a hacker is trying to use the brute-force method to guess a password for an account, you should be able to lock out the account automatically after a specified number of attempts within a specific time frame.

Password Grabbers

About the oldest trick known to those who would want to break into another user’s account is the use of a program that imitates the operating system’s own logon procedure. This kind of program generally is executed by someone who logs in using his own account on another’s workstation. He then runs a program that does nothing but wait until the unsuspecting user tries to log in. The program prompts for a username and password, mimicking the operating system in every respect. However, instead of logging the user on to the system, which the program is unable to do, it simply stores the password in a file and then generates a phony error message.

If the user is not too concerned about security, he will probably never know that he has been fooled. The user might think he has entered his password incorrectly and try again. The second time it will succeed because it is the operating system that is prompting the user this second time. The password grabber program has already done its job and it disappears.

The user who began this fraud simply retrieves the file, thus getting the password, and then can freely log in as that user and cause many problems when it comes to tracking down the real person who is abusing security. Because the perpetrator is now using someone else’s username and password, he is difficult to catch.

System Daemons and Services

Windows servers have background processes that perform many functions, called services. Unix systems also have background processes that work in a similar manner that are called daemons. Regardless of what you call them, these processes, which are called background because they do not require interaction with the keyboard but instead execute on the computer waiting to perform some function, can introduce security problems when they are not needed.

You should become familiar with the background processes on any servers in your network and disable those that are not needed. For example, on Unix systems, there are many background daemons associated with the TCP/IP suite of protocols. Some systems might need all of these, whereas some might need just a few or none of them. Table 42.1 lists some of the daemons you might want to look at to determine whether they are needed. If not, disable them.

Table 42.1. TCP/IP Services That Might Not Be Needed on All Systems

It might be that you do need these services. It might be that they need to be configured properly to prevent their misuse. You should read the documentation that comes with your Unix or Linux system to determine the capabilities that these daemons provide and disable them on systems that do not need them.

For example, tftp (the trivial ftp transport application) is a stripped-down version of FTP. It is compact and usually can be easily implemented in an EPROM. For this reason, it is useful in some devices that need to download operating software from a host. However, note that unlike FTP, tftp has no access control mechanisms. This means that a username and password are not used. Because there is no authentication, this can be a real security problem if it is not configured properly, such that it can be used only for its intended purpose.

On Windows servers, you can use two programs that are provided with the Resource Kits to install or run almost any executable program or batch file as a service. These are INSTRV. EXE, which can be used to install an executable, and SRVANY. EXE, which can be used to make other kinds of files into services. On a server that has several users logging in frequently, you might want to make it a regular part of your routine maintenance to review the services running on the machines and disable or remove those that are not installed by the initial operating-system installation or those that did not come from products you have applied to the system.

To do this, you will need to keep an inventory of what runs on each server, but this kind of inventory information can be useful for other purposes, such as when you need to reinstall a server that has been destroyed by a catastrophic failure.

Removing Dead Wood

Every operating system comes with default options installed that you might not be aware of unless you have read the documentation carefully. For example, default user accounts might be created when you install the OS or later install a product. For example, the GUEST account in Windows operating systems is installed by default. You should always disable or remove this account. The Administrator account is also a vulnerable target because it is present on all Windows Server computers from Windows NT through Server 2003. You cannot delete this account, but you can rename it so that the hacker’s job becomes more difficult. Also, you shouldn’t use the Administrator account on a regular basis. Instead, create individual administrative user accounts for each system administrator trusted to perform these high-level tasks. Then put them into the Domain Admins group to allow these users to exercise administrator privileges, while maintaining an audit trail of the actual users who performed certain actions. You should always use separate administrative accounts for your domain administrators. Never use the same account for domain administration as is used for regular user functions. Administrators should be logged in with administrative accounts only when performing activities that require elevated permissions. You can also use group policies to further restrict what each user can do.

Regularly review the user accounts that exist on the network. Use the auditing features provided to determine when an account has not been in use for a long period, and if you can find no reason for its existence, disable it. Maybe someone in another department did not notify you when a user was terminated, or maybe an account was created for an expected new employee or contractor who later changed his mind and did not come on board. New accounts such as these are typically created with a simple password and can leave gaping security holes in your network.

Old programs and files that are no longer needed, or the use for which you are not sure, are also easy targets to cause security problems. As a rule of thumb, if it’s not needed, back it up to tape and delete it! If a user finds that something she needs is missing, she will tell you!

When installing a new application product for a user, be sure you know the capabilities of the application. Don’t install unneeded optional features that will not normally be used. Read the documentation!

Delegating Authority

In a network of any size other than a simple workgroup, it is usually necessary to delegate authority to other administrators or middle-level management personnel. When you find that you must create accounts that have privileges to perform administrative functions, do not give carte blanche access to every account. Keep track of the exact functions an account will be used for, and grant only the access rights and permissions needed.

For example, if an operator will be performing backup functions on a server, he does not need to have full rights and privileges on the server. Under Windows Servers, you can place the user’s account into the Backup Operators user group to give him the capabilities he needs, without compromising all files on the system. If you have users who must be able to add or modify user accounts, check the operating-system documentation and give the users access only to the resources and data files they need.

User Accounts

Generic accounts might seem like a good idea at first thought, but they provide nothing in the way of auditing. If you simply let one or more users share the root account on a Unix system, or the Administrator account on a Windows server, you will have no way of determining tracking, and resolving who did what when something goes wrong. Indeed, because you can grant the same capabilities to any new account you can create, why not do so?

Give each user who requires elevated capabilities her own account, and grant the necessary privileges to the account. This way you can track each user to be sure she does not abuse her account or use it in a way you do not expect.

When you have more than one user using the same account, there is also the likelihood that the password will be compromised and someone who is not authorized to use the account will do so.

Application Servers, Print Servers, and Web Servers

One particularly common error you can make is to put all your eggs in one basket. Instead of using one server to provide print services or file services or Web services, many administrators use one server to provide all three. This is not necessarily a good idea.

Specialized servers can limit the damage that can be done by intruders and also can make it easier to delegate authority so that a particular administrator can concentrate on a limited set of functions for a certain server. Web servers are particularly prone to attempts by hackers to intrude onto your network. New applications and technologies are being developed and deployed all the time, and the newer they are, the more likely it is that they will have bugs or other loopholes that make them more risky than other applications that run on the network.

Placing sensitive data files on a Web server simply because it is convenient to use the machine’s resources is not a good idea if it is also being used as a Web server. Make it more difficult to get at these files by dedicating a file server computer to them instead.

Delegating servers is almost like delegating authority to users. When you divide up resources and partition them into manageable groups, you make it less likely that an attack on one object will result in damage to all objects.

Denial of Service (DoS) attacks are very common on networks now. This kind of attack can be done by a malicious person who takes advantage of a known weakness in a protocol or an implementation of a particular service. One common mistake that administrators make when setting up an FTP site is to place it on an ordinary server.

For example, you might want to have an FTP server that allows customers to log in to your system and download information, patches, or other files. You also might want to be able to let them upload files or messages to your site. If you are going to allow anonymous FTP access, be absolutely sure that the service is configured so that it can access only a dedicated disk or set of disks. Do not allow anonymous access to an FTP service that writes to a system disk or a data disk that is important in your network. It is quite easy for an outsider to simply fill up the disk with meaningless data, causing a system to lock up or crash, depending on the operating system. If an important data disk becomes full, it can cause an extended period of downtime, putting employees out of work for hours while you try to first determine the cause and then remedy it!

Don’t Forget About Firewalls

Last, but not least, for this chapter is a quick reminder that a firewall is a necessity for connecting a LAN or larger network to the Internet today. A firewall can serve to prevent the spread of all sorts of trouble that can be perpetuated on the Internet using freely available tools and script files that even high-school kids can download and use to wreak havoc on the network that becomes their target. Using a “demilitarized zone” with a firewall can allow you to provide access to users outside of your network, as well as access by users inside your network. The benefit is that the servers are placed between two firewalls, and access to these types of servers is done on a controlled basis.

Chapter 45 should be considered required reading material for any network administrator who cares about security, whether it be a large network or a small office network. Firewall technology can be simple (but easily hacked), or it can be a full-time job for several people in a large network. Justify the cost by comparing what it will cost you if your data is changed, obtained by a third party, or just hacked by some person on the Internet who gets his kicks out of causing you problems!