Physical and Logical Security
Security can be broken down into two distinct areas: physical security and logical security. Physical security refers to the issues related to the physical security of the equipment that comprises or is connected to the network. Physical security includes controlling access to equipment, supervising visitors, and enforcing the security measures that are in place, to control physical access to areas that contain networking equipment.
Logical security is concerned with security of data while it is on the systems that are connected to the network. Logical security involves controlling passwords and password policies, controlling access to data on servers through file system security, controlling access to backup tapes, and perhaps most importantly, preventing sources outside the network from gaining access to the network through a connection from another network, such as the Internet. Because logical security is a large and complex topic, this chapter covers only topics related to the Network+ exam and some supporting information.
Physical Security
Physical security is concerned with the prevention of unauthorized access to the physical equipment that makes up the network or the systems attached to it.
Perhaps the biggest consideration related to physical security is restricting access to networking equipment and servers. Most commonly, the people you are trying to protect against in this respect are the employees of the company rather than malicious outsiders.
EXAM TIP
Physical Security The Network+ exam focuses much more on logical security than on physical security. For this reason, the discussion of physical security is confined to just the basics.
Specific physical security considerations include the following:
Controlling access to equipment— Networking equipment should be kept in a secure location. For example, you might have a dedicated, environmentally controlled room in which all the network servers and networking equipment are kept.
Alternatively, as in many small organizations, networking equipment might be stored in a cupboard or even a rack. Wherever your equipment is located, access control systems (including locks and keys) should be in place to prevent unauthorized access.
Creating and enforcing visitor policies— Even if you have a dedicated server room, it's highly likely that there will be other equipment in the room, such as telephone systems, air- conditioning units, and fire-protection systems. Each of these systems will have a scheduled maintenance program, which means that you will periodically have visitors in the server room. Procedures should be in place so that the identities of visitors are verified, and that when these visitors are in the equipment room, they are supervised.
Securing the area— The physical security of the network environment should be examined from a big-picture perspective. If a dedicated room is used for the server, determine the security of the room. Are there windows in the room that might represent a security risk? Are there windows that could facilitate someone outside the building seeing in? All these aspects and more must be factored in when considering physical security.
Logical Security
Logical security is a much more involved subject than physical security. Not only are there more ways in which data can be threatened logically than physically, but the measures available to secure data are equally diverse. This section focuses on two of the most significant aspects of logical security: authentication and file system security.
NOTE
Hacker or Cracker? The terms hacker and cracker are tossed about quite freely when it comes to network security, but the two terms describe very different individuals. A hacker is someone who attempts to disassemble or delve into a computer program with the intention of understanding how it works, normally in order to make it better. A cracker, on the other hand, is someone who attempts to gain access to a computer system or application without authorization, with the intention of using the application illegally or viewing the data. Crackers, not hackers, are the people network administrators need to be concerned with.
Authentication, Passwords, and Password Policies
Although there are many different methods of authentication, none have attained the level of popularity of username and password combinations. The reason is that, apart from the fact that usernames and passwords do not require any additional equipment, which practically every other method of authentication does, the username and password process is familiar to users, easy to implement, and relatively secure. In the future, other authentication methods, such as biometrics (for example, fingerprint recognition, retinal scans), might overtake usernames and passwords in popularity, but if they ever do, that day is some time away.
Before we talk about some of the specific considerations for working with usernames and passwords, we should perhaps answer a simple question. Why do we need usernames and passwords in the first place? The obvious answer, of course, is that they provide a mechanism for users to prove that they are entitled to access the network or a specific resource. But there is another reason: accountability. If users must prove their identity, they are made accountable for their actions. This is particularly relevant in environments in which the auditing of system events is performed because it allows events to be attributed to certain users, based on their usernames. Without some form of authentication—be it usernames and passwords or something else—users cannot be held accountable for their actions.
Passwords are a relatively simple form of authentication in that only a string of characters can be used. However, how the string of characters is used and what policies you can put in place to govern them make usernames and passwords such an excellent form of authentication.
Password Policies
All popular network operating systems include password policy systems that allow the network administrator to control how passwords are used on the system. The exact capabilities vary between network operating systems. However, generally they allow the following:
Minimum length of password— Shorter passwords are easier to guess than longer ones. Setting a minimum password length does not prevent a user from creating a longer password than the minimum, although each network operating system has a limit on how long a password can be.
Password expiration— Also known as the maximum password age, password expiration defines how long the user can use the same password before having to change it. A general practice is that a password is changed every month or every 30 days. In high-security environments, you might want to make this value shorter, but you should generally not make it any longer. Having passwords expire periodically is an important feature because it means that if a password is compromised, the unauthorized user will not have access indefinitely.
Prevention of password reuse— Although a system might be able to cause a password to expire and prompt the user to change it, many users are tempted to simply use the same password again. A process by which the system remembers the last, say, 10 passwords is most secure because it forces the user to create completely new passwords.
Prevention of easy-to-guess passwords— Some systems have the capability to evaluate the password provided by a user to see if it meets a required level of complexity. This prevents users from having passwords such as password or 12345678.
EXAM TIP
Enforcing Password Changes On the Network+ exam, you will need to identify an effective password policy. For example, a robust password policy would include forcing users to change their passwords on a regular basis.
The process of setting password policies differs between network operating systems. As an example, Figure 12.1 shows the Password Policy configuration screen on a Windows 2000 Server system.
Figure 12.1. The Password Policy configuration screen in Windows 2000.
Each network operating system uses slightly different terms to describe the parameters that can be set in the password policy, although the options are similar across all network operating systems. For more information, consult the documentation for your network operating system. (Exercise 12.2 at the end of this chapter describes how to set the password policy on a Windows 2000 Active Directory system.)
Understanding Password Strength
No matter how good a company's password policy, it is only as effective as the passwords that are created within it. A password that is hard to guess, or strong, is more likely to protect the data on a system than one that is easy to guess, or weak.
NOTE
The Administrator's Password The password used to log on to the Administrator account are, without question, the most valuable of all the passwords on the system. For that reason, you should treat them with an even greater level of respect than the passwords for normal user IDs. Administrator account passwords should, ideally, be changed more often than standard user account passwords, and they should also be as hard to guess or crack as possible.
To understand the difference between a strong password and a weak one, consider this: A password of six characters that uses only numbers and letters and is not case-sensitive has 10,314,424,798,490,535,546,171,949,056 possible combinations. That might seem like a lot, but to a password-cracking program, it's really not much security. A password that uses eight case-sensitive characters, with letters, numbers, and special characters has so many possible combinations that a standard calculator is not able display the actual number.
There has always been debate over how long a password should be. It should be sufficiently long that it is hard to break but sufficiently short that the user is able to easily remember it (and type it). In a normal working environment, passwords of 8 characters are seen as sufficient. Certainly, they should be no fewer than 6 characters. In environments where security is a concern, passwords should be 10 characters or more.
Users, You Are the Weakest Link
For all your efforts to create and implement a strong password policy and system, there is normally one weak link in the chain—the user. You can specify that passwords be a minimum of 10 characters and that the user is not allowed to reuse an old password. However, that still doesn't stop the user from using a password like peterdecember for December and peterjanuary in January. As discussed earlier in this chapter, some authentication systems do have mechanisms that try to detect easy-to-guess passwords and prevent users from setting them, but its effectiveness is limited to only basic character sequences/dictionary words. For example, they would not dispute a Social Security number combined with the user's name. This might constitute a strong password in terms of characters used to create it and length, but it would still be potentially easy to guess for a password cracker.
NOTE
Weak Passwords The Computer Emergency Response Team (CERT) Coordination Center estimates that four out of five network security incidents are caused by weak passwords.
The best way to deal with these situations is education. You must educate users so they understand why passwords are used, their purpose, and what the rules are to create them. You should also tell users what are and are not considered acceptable passwords. In the 21st century, you might think that users would automatically understand the need for strong and hard-to-guess passwords, but the reality is different. Users are notorious for choosing easy-to-guess passwords, such as their surname, a spouse's name, a pet's name, a home address, or a vehicle license plate number. This is the kind of information that a password cracker will try first when attempting to crack a password.
Users should be encouraged to use a password that is considered strong. A strong password has at least eight characters; has a combination of letters, numbers, and special characters; uses mixed case; and does not form a proper word. Examples might include 3Ecc5T0h and e1oXPn3r. Such passwords might be secure, but users are likely to have problems remembering them. For that reason, a strategy that is popular is to use a combination of letters and numbers to deform phrases or long words. Examples include d1eTc0La and tAb1eT0p. These passwords might not be quite as secure as the preceding examples, but they are still very strong and a whole lot better than the name of the user's household pet.
Passwords: The Last Word
One last password-related topic is worth mentioning. A password is effective only if just the intended users have it. As soon as a password is passed to someone else, its effectiveness as an authentication mechanism is diminished, and as a tool for accountability, the password is almost useless. Passwords are a means of accessing a system and the data on it. Passwords that are known by anyone other than the intended user(s) might as well not be set at all.
File System Security
Because they are the heart of the system, network operating systems are chock full of security-related features and subsystems. All popular network operating systems have robust authentication systems that control access to the network and file system security measures which ensure that users can view and use only the data they are supposed to. Chapter 9, “Network Operating Systems and Clients,” discusses the authentication methods used by the various network operating systems, so this chapter does not cover that again. Instead, the following sections take a more in-depth look at the file system security measures on the popular network operating systems.
After logon security, file system security is perhaps the most important aspect of system security. If you have a solid file system security structure in place, even if someone does manage to gain unauthorized access to the system, the amount of damage he or she is able to do can be limited.
Novell NetWare File System Security
File system security on NetWare is the most sophisticated of any of the popular network operating systems. In addition to a full set of file permissions, NetWare also accommodates file permission inheritance, as well as filters to cancel out that inheritance. For those who are unfamiliar with the various features of NetWare file system security, it can seem a bit bewildering. When you are used to it, though, you realize that it allows an extremely high level of control over files and directories.
NOTE
Inheritance The term inheritance is used to describe the process of rights flowing down the directory tree. For example, rights are assigned at the top of the directory structure, and unless they are blocked at a lower level, they flow to the bottom of the structure. All common network operating systems employ file inheritance in one way or another.
At the core of NetWare file system security are the basic permissions. These permissions can be assigned to individual files or, where appropriate, directories (that is, folders). The file system rights available on a NetWare server are listed in Table 12.1.
Figure 12.2 shows a file permission assignment on a NetWare 6 server.
Unix/Linux File System Security
Of the platforms discussed in this chapter, Unix and Linux have the most simplistic approach to file system security, although for most environments, this approach is more than sufficient. File permissions can be assigned to either the creator of a file or directory, a group, or the entity “everyone,” which includes any authenticated user.
Unix and Linux have only three rights that can be assigned. These rights are listed in Table 12.2.
| Right | Description |
|---|---|
| Read | Allows files to be listed, opened, and read |
| Write | Allows files to be created, written to, or modified |
| Execute | Allows the file to be executed (that is, run) |
Figure 12.3 shows a directory listing from a Linux server with the assigned permissions for each file or directory. The file permissions are listed to the right of the file. The first value specifies whether the file is a file (-) or a directory . The next three values specify the file rights for the user, the next three for the group, and the next three for the “everyone” assignment.
Windows NT 4 and Windows 2000 File System Security
Both Windows NT 4 and Windows 2000 use the New Technology File System (NTFS) to provide file system security. Rights can be assigned to users, groups, and some special entities, which include the “everyone” assignment. Table 12.3 describes the basic file permissions that can be used with NTFS on Windows NT 4 and Windows 2000.
Figure 12.4 shows the Disk Properties screen, through which file permissions are assigned.
Figure 12.4. The Disk Properties screen, through which file permissions are assigned.
An added complexity to file system security on Windows platforms is that the shares created to allow users to access folders across the network can also be assigned a set of permissions. Although these permissions are quite basic (Full Control, Change, and Read), they must be considered because they can be combined with NTFS permissions. The rule when this situation occurs is that the most restrictive permissions assignment applies. For example, if a user connects through a share with Read permission and then tries to access a file to which he has the NTFS Full Control right, the actual permissions would be Read. The most restrictive right (in this case, Read) overrides the other permissions assignment.
EXAM TIP
Know the File Permissions On the Network+ exam, you might be asked to identify valid and invalid file permissions for certain platforms.
File Permissions Best Practices
In an ideal world, each and every file and directory would be assigned exactly the needed set of permissions that allows each and every user only the required level of access. If you have just a few dozen files, such an approach might be possible. But in the real world, where servers might have 200,000 files or more, it's simply not feasible.
The commonly adopted solution is to assign rights to directories (that is, folders) rather than files and then try to group files that have a similar level of access together in one location. If such a system is implemented carefully, it can work very well. However, it requires certain considerations, such as whether there are groups of files that require the same access, and it can be implemented only in environments where file system security is not a great concern.