| There are many potential threats to security, and an entire science and industry have grown up around this important area. Several good books on the subject, which we mention in the Further Reading section at the end of this chapter, provide excellent coverage of security in general and treat the subject in a more complete and formal manner than we will here. Because the subject of this book is directories, not security, we will take a more pragmatic and focused approach toward describing the range of security threats. This section provides an example-driven overview of the most typical threats to directory security. We've divided the threats into three categories: unauthorized access, tampering with information, and denial of service. It's important to understand that an attacker does not necessarily have to be particularly clever to launch one of these types of attacks. With the popularity of the Internet and the growth of the bad-guy community along with it, the advantages of shrink-wrapped software have come to computer security attacks. For most of the threats we describe in this chapter, you can find ready-made software that will exploit them. People trying to compromise your security are often just running shell scripts and programs they downloaded off the Internet. These "script kiddies," as they are known, may have less of an idea how the programs operate than you do! Of course, there are exceptions, too: Wily hackers who discover security holes and write the programs that exploit them are still in abundance . A commonly held security myth is that most attacks are made by hackers operating out of their basement computing lairs. In reality, most attacks, especially successful ones, are made by your own employees , administrators, and users. In practice, the inside job poses by far the greatest threat to your directory's security in most environments. When designing your security solution, be sure to consider threats both inside and outside your organization. Unauthorized Access The threat of unauthorized access may seem simple to protect against. You should authenticate clients accessing your directory and provide access control restricting the information that these clients can view. Problem solved , right? Unfortunately, it's not quite that easy. Think about the way directory information is delivered to authorized clients. There are several opportunities along this path for an unauthorized client to gain access to the data. Here are several breaches that can occur: -
Credential forging . If a client's credentials can be forged, an unauthorized client can fool the directory into thinking it is authorized. For example, suppose that your directory's authentication scheme is based on plaintext passwords, and no other steps are taken to protect the password as it is transmitted to the server. An attacker who is able to watch a legitimate client in an authentication exchange may be able to replay the exchange later, successfully masquerading as the legitimate client. Encryption technologies can reduce this risk by making it difficult for an attacker to obtain the information necessary to mount a replay attack. -
Credential stealing . This threat is closely related to credential forging but more low-tech in nature. If your users write down their passwords on notes stuck to their computers, anyone who walks by can steal them. If you use token-based security that requires the user to present a physical token to access the directory, this token can be stolen. The same is true for schemes based on public key cryptography. Each user has a public key that is shared with others, and a private key that is kept secret. If a user's private key is stolen, the thief can impersonate the user. Credentials can be stolen in a variety of ways ”many of them not technology based. Make sure that your users know never to give their password or key to anyone, not even an employee of your own Help Desk. -
Connection hijacking . Is it possible for an unauthorized client to hijack an authorized client's connection when the authorized client has authenticated itself? Yes, barring any connection-level protection that prevents it. For this to happen, the hijacker usually has to have access to the same physical network that the victim is on. Methods of attack vary somewhat, but they all involve the hijacker responding to requests meant for the authorized client and preventing the client from responding. General connection protection mechanisms, such as Secure Sockets Layer (SSL) or its successor, Transport Layer Security (TLS), can prevent this. SSL and TLS are discussed in more detail in the next section, Security Tools. -
Network sniffing . If it is possible for attackers to eavesdrop on the information exchanged between a legitimate client and the server, they can learn things they are not authorized to know. To guard against this possibility, steps must be taken either to physically protect the network between clients and servers so that no one can listen in, or to protect the information exchanged so that an eavesdropper who does listen in cannot get useful information. SSL and TLS provide these benefits by encrypting the information transferred. Other schemes have this property, but SSL and TLS are by far the most widely used. -
Trojan horses . Remember that there can be a lot of software between an authorized directory user (or other agent) and the network that conveys that information. A Trojan horse is software that masquerades as a legitimate program but, when run, performs some illicit functions that compromise security. A popular kind of Trojan horse program is a keystroke sniffer , which disguises itself as a legitimate login program. This nasty piece of software hooks into the low-level routines taking input from your keyboard, recording all keystrokes you make. These keystrokes can be analyzed later to determine such private information as your password. To protect against Trojan horses, you can use a system integrity verifier, which we discuss in the next section, Security Tools. -
Backdoor access . Are there possibly other ways to access the data you want to protect ”ways not subject to your directory's authentication and access control safeguards? The answer is almost certainly yes. Directory data lives on one or more server machines, probably residing in some kind of database or file system. If an intruder gains unauthorized access to the directory server machine, he or she has a wide variety of opportunities to access the data. If your directory data comes to your server in a feed from the Human Resources relational database, the information in your directory is only as secure as the source database. Many other avenues of access to your data are possible, in addition to the directory access methods you are designing. -
Physical access . Obvious, perhaps, but worth mentioning is the fact that if an attacker has physical access to the directory server machine, he or she can cause a whole host of problems. These range from gaining increased privileges by logging in via a console or other trusted terminal, to just being able to unplug the disk drive containing the directory data and walk out the door with it. Keeping your server machines in locked rooms with limited access is a good guard against this possibility. Encrypting directory data as it lives on the server is another good approach, although this can be expensive. Performance suffers because of the time it takes to encrypt and decrypt data. Extra hardware may be required to make performance acceptable. Also be sure to secure any backup copies of your directory data, including those stored in off-site locations. -
Software bugs . This category is a bit of a catchall , representing today's most commonly exploited security problem: bugs. Bugs in the directory server software, the operating system, shared libraries, and even unrelated systems can often be exploited by an attacker to gain unauthorized privileges. Hackers often use prepackaged scripts designed to locate servers that are vulnerable because of a known bug. These scripts often exploit the vulnerability and install a special backdoor access method for the hacker. Systems compromised in this way can be exploited, or used as a launchpad for further attacks mounted from inside your corporate network. To protect against these types of attacks, stay abreast of security patches available from vendors and install them as soon as they become available. You can also reduce your risk by using firewall technology to close off access to all network ports except the ones that need to be accessible via the Internet. For more information on this important subject, consult one of the general texts on security mentioned in the Further Reading section at the end of this chapter. Unauthorized Tampering Access to directory data is one thing, but if an attacker can actually change directory data ”either as it resides in the service itself or en route between client and server ”a new set of problems arises. If that were to happen, clients could no longer trust the information they received from the directory, servers could no longer trust the modifications and queries they received from clients, and the directory service would soon become useless. Many of the attacks described in the previous section could result in data tampering, as could other new attacks. Here are the attack methods you need to be concerned about: -
Man in the middle . In one common attack of this kind, an attacker is able to insert himself between the directory client and server. Without any means to detect tampering, the man in the middle could change the client's requests to the server (or not forward them at all) and change the server's responses to the client (see Figure 12.1). SSL and TLS can solve this problem by signing information at either end of the connection. If the signature is invalid when the data arrives, the data has been tampered with. Figure 12.1. The "Man in the Middle" Security Attack  -
Trojan horse . As with unauthorized access to data, a Trojan horse attack on a directory client (or server) can easily facilitate unauthorized tampering. The same countermeasures as for man in the middle apply, as do the same difficulties in applying them. -
Masquerading . In the preceding section we described several ways that a client can fool a server into thinking that the client is someone else. The same problems apply here, for both client and server. A client that can masquerade as somebody else can insert false information into the directory. An evil server that can masquerade as a legitimate server can send back incorrect information to clients and prevent legitimate client modifications from being made. Denial-of-Service Attacks Another kind of security threat to your directory does not involve stealing or changing data at all. Instead the attacker's goal is to prevent the directory from providing service to its clients. Such an attack is called a denial-of-service ( DoS ) attack. DoS can be one of the hardest security problems to guard against and detect. There are two main types of DoS attacks: -
Direct resource consumption . This is a general kind of attack in which the attacker simply uses the system's resources to prevent them from being used by someone else. For example, someone could write a directory client that continuously performs expensive directory operations, tying up the resources and making them unavailable to other users. Someone could also write a directory client that stores large amounts of information in the directory in an attempt to exhaust available disk space. There are many other forms of this attack as well. Placing limits on the number of directory resources that any single client or user can use is a good way to guard against direct resource consumption. Keeping good audit records for the directory is also a good idea. Although an audit record does not prevent the attack, it does allow you to determine when it is happening, and perhaps who is perpetrating the attack and how to stop it. Monitoring can also help fight this problem. If you know the normal level of resource consumption by your directory, monitoring can alert you to any unusual events. Hopefully you will be able to take action before the problem gets out of hand. Monitoring is discussed in more detail in Chapter 19, Monitoring. -
Indirect resource consumption . This attack is similar to the direct attacks just described, but it is often more difficult to detect and guard against. Indirect resource consumption is the use of resources that the directory server or directory clients need, thus denying those resources to the legitimate users. The difference between this and the direct attack is that the directory service itself is not involved, so directory auditing capabilities often don't help in detection and prevention. For example, an attacker could write a program that uses inordinate amounts of bandwidth. Another attacker with access to the directory machine could write a program to consume CPU, disk bandwidth, memory, or other resources. Much more clever and insidious attacks are possible, too, such as initiating half-opened connections to the directory machine until the machine runs out of system resources. The list of possibilities goes on ”and can get nasty. This kind of attack is difficult to defend against, but you can take some precautions . Isolating your directory machines as much as possible is a good start. Reducing the number of nondirectory processes and users on the directory server machines (or, ideally , eliminating them) is another good idea. Employing firewall filters and other network-level safeguards is also possible. No amount of prevention can eliminate the threat, but it can be reduced. In addition to traditional DoS attacks, a more sinister variant, the distributed denial-of-service ( DDoS ) attack, has become increasingly common. In a DDoS attack, the perpetrator exploits known security holes to attack vulnerable servers. If the attack is successful, a special piece of software is installed that can mount a DoS attack and can be remotely controlled by the hacker. When the hacker has tens or hundreds of compromised servers at his disposal, he can instruct all of them to attack a single target system simultaneously . There are several reasons someone might conduct a DoS attack on your directory. The first and probably most likely is simply by mistake. Bugs in directory client software, misconfigured software, or simply a lack of awareness of the consequences of certain actions can all lead to DoS. Your best guards against this kind of attack are education, monitoring, and auditing. The second reason someone might conduct a DoS attack on your directory is simple maliciousness. The attacker might be out to ruin your day or the days of your users. The attacker might have a specific problem with you or your service, or your service might simply provide a convenient target for wreaking general havoc. Either way, you would do well to guard against this kind of attacker. The final and most insidious reason someone might conduct a DoS attack on your directory is to help him compromise another system that depends on the directory. For example, if your Web server depends on the directory to authenticate users, attacking the directory can effectively disable the Web service. This kind of attack can be difficult to defend against because the real motivation behind the attack may never be known. |
