CompTIA Network+ Certification Study Guide part 47 ppsx

ChApTEr 9: Security Standards and Services 446 As seen in Figure 9.15, two events are occurring as credentials are pre- sented (password, Smart Card, biomet- rics) to the KDC for authentication. This is due to the dual role of the KDC. It acts as both an Authentication Server and as a Ticket Granting Server. First, the authentication credential is pre- sented to the KDC where it is authen- ticated using the Authentication Server mechanism. Second, the KDC issues a Ticket Granting Ticket (TGT) through the Ticket Granting Server mechanism that is associated with the access token while you are actively logged in and authenticated. This TGT expires when you (or the service) disconnect or log off the network, or after it times out. The Kerberos administrator can alter the expiry timeout as needed to fit the organizational needs, but the default is one day (86,400 s). This TGT is cached locally for use during the active session. Figure 9.16 shows the process for resource access in a Kerberos realm. It starts by presenting the previously granted TGT to the authenticating KDC. The authenticating KDC returns a session ticket to the entity wishing access to the resource. This session ticket is then presented to the remote resource server. The remote resource server, after accepting the session ticket, allows the session to be established to the resource. Kerberos uses a time stamp and we need to understand where and when the time stamp is used. The time stamp is used to limit the possibility FIGurE 9.15 Authentication Path for Logon Access in a Kerberos Realm. FIGurE 9.16 Resource Access in Kerberos Realms. Network Access Security 447 of replay or spoofing of credentials. Replay is the capture of information, modification of the captured information, and retransmission of the modi- fied information to the entity waiting to receive the communication. If unchecked, this allows for impersonation of credentials when seeking access. Spoofing is the substitution of addressing or authentication infor- mation to try to attain access to a resource based on information acceptable to the receiving host, but not truly owned by the sender. The initial time stamp refers to any communication between the entity requesting authen- tication and the KDC. Normally, this initial time period will not be allowed to exceed 10 minutes if it is based on the MIT Kerberos software default. Microsoft’s Kerberos implementation has a five-minute time delta. If clocks are not synchronized between the systems, the credentials (tickets) will not be granted if the time differential exceeds the established limits. Session tickets from the KDC to a resource must be presented within this time period or they will be discarded. The session established between the resource server and the requesting entity is also time-stamped but generally lasts as long as the entities logon credential is valid. This can be affected by system policies like logon hour restrictions, which are defined in the origi- nal access token. TGT tickets are not part of the default five-minute period, rather they are cached locally on the machine and are valid for the duration of the logged-on session. LDAP Directory services are used to store and retrieve information about objects, which are managed by the service. On a network, these objects can include user accounts, computer accounts, mail accounts, and information on resources available on the network. Because these objects are organized in a directory structure, you can manage them by accessing various properties associated with them. For example, a person’s account to use the network would be managed through such attributes as their username, password, times they’re allowed to logon, and other properties of their account. By using a directory service to organize and access this information, the objects maintained by the service can be effectively managed. The concept of a directory service can be somewhat confusing until you realize that you’ve been using them for most of your life. A type of directory that has been around longer than computers is a telephone directory, which organizes the account information of telephone company customers. These account objects are organized to allow people to retrieve properties such as the customer’s name, phone number, and address. Directory services shouldn’t be confused with the directory itself. The directory is a database that stores data on the objects managed through ChApTEr 9: Security Standards and Services 448 directory services. To use our telephone directory example again, consider that the information on customer accounts can be stored in a phonebook or electronically in a database. Regardless of whether the information is accessed through an operator or viewed online using a 411 service, the directory service is the process of how the data is accessed. The directory service is the interface or process of accessing information while the direc- tory itself is the repository for that data. Directory services are used by many different network OSs to organize and manage the users, computers, printers, and other objects making up the network. Some of the directory services that are produced by vendors include the following: Active Directory, which was developed by Microsoft for networks  running Windows 2000 Server, Windows 2003 Server, or Windows 2008. eDirectory, which was developed by Novell for Novell NetWare net- works. Previous versions for Novell NetWare 4.x and 5.x were called Novell Directory Services (NDS). OpenLDAP, which was developed by Apple for networks running  Mac OS X Servers. To query and modify the directory on TCP/IP networks, the LDAP can be used. LDAP is a protocol that enables clients to access information within a directory service, allowing the directory to be searched and objects to be added, modified, and deleted. LDAP was created after the X.500 directory specification that uses the Directory Access Protocol (DAP). Although DAP is a directory service standard protocol, it is slow and somewhat complex. LDAP was developed as an alternative protocol for TCP/IP networks because of the high overhead and subsequent slow response of heavy X.500 clients, hence the name lightweight. Because of the popularity of TCP/IP and the speed of LDAP, the LDAP has become a standard protocol used in directory services. LDAP services are used to access a wide variety of information that’s stored in a directory. On a network, consider that the directory catalogs the name and information on every user, computer, printer, and other resource on the network. The information on a user alone may include their user- name, password, first name, last name, department, phone number and extension, e-mail address, and a slew of other attributes that are related to the person’s identity. The sheer volume of this data requires that LDAP directories are effectively organized so that the data can be easily located and identified in the directory structure. Network Access Security 449 LDAP Directories Because LDAP is a lightweight version of DAP, the directories used by LDAP are based on the same conventions as X.500. LDAP directories follow a hier- archy, much in the same way that the directories on your hard drive are organized in a hierarchy. Each uses a tree-like structure, branching off a root with containers (called organizational units in LDAP, analogous to folders on a hard drive) and objects (also called entries in LDAP’s directory, analogous to files on a hard drive). Each of the objects has attributes or properties that provide additional information. Just as a directory structure on a hard disk may be organized in different ways, so can the hierarchy of an LDAP direc- tory. On a network, the hierarchy may be organized in many ways, follow- ing the organizational structure, geographical location, or any other logical structure that makes it easy to manage the objects representing users, com- puters, and other resources. Because LDAP directories are organized as tree structures (sometimes called the Directory Information Tree [DIT]), the top of the hierarchy is called the root. The root server is used to create the structure of the directory, with organizational units and objects branching out from the root. Because the directory is a distributed database, parts of the directory structure may exist on different servers. Segmenting the tree based on organization or division and storing each branch on separate directory servers increase the security of the LDAP information. By following this structure, even if one directory server is compromised, only a branch of the tree (rather than the entire tree) is compromised. Organizational Units The hierarchy of an LDAP directory is possible because of the various objects that make up its structure. These objects represent elements of the network, which are organized using containers called organizational units (OUs). Each OU can be nested in other OUs, similar to having subfolders nested in fold- ers on your hard disk. In the same way, the placement of folders on your hard disk makes a directory structure, the same occurs with OUs and objects in an LDAP directory. The topmost level of the hierarchy generally uses the DNS to identify the tree. For example, a company named Syngress might use syngress.com at the topmost level. Below this, organizational units are used to identify different branches of the organization or network. For example, you might have the tree branch off into geographical locations, such as PARIS, LON- DON, and TORONTO, or use them to mimic the organizational chart of the company and create OUs with names such as ADMINISTRATION, ChApTEr 9: Security Standards and Services 450 RESEARCH, TECHNOLOGY, and so forth. Many companies will even use a combination of these methods and use the OUs to branch out by geo- graphical location, and then create OUs for divisions of the company within the OUs representing locations. To identify the OUs, each has a name that must be unique in its place in the hierarchy. For example, you can’t have two OUs named PRINTERS in a container named SALES. As with many elements of the directory, it is analogous to the directory structure of a hard disk where you can’t have two subfolders with the same name in the same folder. You can, however, have OUs with the same name in different areas of the hierarchy, such as having an OU named PRINTERS in the SALES container and another OU named PRINTERS in an OU named SERVICE. The structure of the LDAP directory is not without its own security risks, as it can be a great source of information for intruders. Viewing the placement of OUs can provide a great deal of information about the network structure, showing which resources are located in which areas of the organization. If an administrator followed a particular scheme of designing the hierarchy too closely, a hacker could determine its struc- ture by using information about the organization. For example, compa- nies often provide their organizational charts on the Internet, allowing people to see how the company is structured. If an administrator closely followed this chart in designing a hierarchy, a hacker could speculate how the LDAP directory is laid out. If the hacker can gain access to the direc- tory using LDAP queries, he or she could then use this information to access objects contained in different OUs named after departments on the chart. Using naming conventions internal to the company (such as calling a London base of operations DISTRICT1) or using some creativity in naming schemes (such as calling an OU containing computer accounts WK instead of WORKSTATIONS) will make the hierarchy’s structure less obvious to outsiders. Although using the organizational chart of a com- pany and geographical locations can be used as a basis for designing the hierarchy, it should not be an easy-to-guess blueprint of the directory and network infrastructure. Objects, Attributes, and the Schema As mentioned, entries in the directory are used to represent user accounts, computers, printers, services, shared resources, and other elements of the network. These objects are named, and as we discussed with organiza- tional units, each object must have a name that’s unique to its place in the namespace of the hierarchy. Just as you can’t have two files with the same name in a folder on your hard disk, you can’t have two objects with the same name in an OU. The name given to each of these objects is Network Access Security 451 referred to as a common name, which identifies the object but doesn’t show where it resides in the hierarchy. The common name is part of the LDAP naming convention. Just as a file- name identifies a file, and a full pathname identifies its place in a directory structure, the same can be seen in the LDAP naming scheme. The common name identifies the object, but a distinguished name can be used to identify the object’s place in the hierarchy. An example of a distinguished name is the following, which identifies a computer named DellDude that resides in an organizational unit called Marketing in the tacteam.net domain: DN: CNDellDude,OUMarketing,DCtacteam,DCnet The distinguished name is a unique identifier for the object and is made up of several attributes of the object. It consists of the relative distinguished name, which is constructed from some attribute(s) of the object, followed by the distinguished name of the parent object. Each of the attributes associated with an object is defined in the schema. The schema defines the object classes and attribute types and allows admin- istrators to create new attributes and object classes specific to the needs of their network or company. For example, a “supervisor” attribute in a user account might contain the name of the user’s manager while a “mail” attri- bute would contain the user’s e-mail address. Object classes define what the object represents (that is, user, computer, and so forth) and a list of what attributes are associated with the object. Because LDAP is binary, to view the attributes of an object, the information can be represented in LDAP Data Interchange Format (LDIF). LDIF is used to show directory entries in an easy-to-follow format and used when requests are made to add, modify, or delete entries in the directory. The following is an LDAP directory entry with several attributes represented in LDIF: dn: cnJohn Abraham, dcsyngress, dccom cn: John Abraham givenName: John sn: Abraham telephoneNumber: 905 555 1212 ext: 1234 employeeID: 4321 mail:jabraham@ssyngress.com manager: Gary Byrne objectClass: organizationalPerson ChApTEr 9: Security Standards and Services 452 As you can see by this entry, the attributes provide a wide degree of information related to the person represented by the object. By looking at this information, we can see contact information, employee identification numbers, the person’s manager, and other data. Other attributes could include the person’s Social Security Number or Social Insurance Number, home address, photo, expense account numbers, credit card numbers issued to the person, or anything else the company wished to include. Although this example reflects a user account, a similar wealth of information can be found in objects representing computers and printers (which would include IP addresses) and other resources on the network. As stated earlier, while useful to authorized users, it is also useful for unauthorized intruders who could use the information for identity theft, hacking specific comput- ers, or any number of other attacks. Securing LDAP LDAP is vulnerable to various security threats, including spoofing of direc- tory services, attacks against the databases that provide the directory ser- vices, and many of the other attack types discussed in this book (for example, viruses, OS and protocol exploits, excessive use of resources and DoS, and so forth.). This isn’t to say that LDAP is completely vulnerable. LDAP supports a number of different security mechanisms, beginning from when clients initially connect to an LDAP server. LDAP clients must authenticate to the server before being allowed access to the directory. Clients (users, computers, or applications) connect to the LDAP server using a distinguished name and authentication cre- dentials (usually a password). Authentication information is sent from the client to the server as part of a “bind” operation, and the connection is later closed using an “unbind” operation. Unfortunately, it is possible for users to make the connection with limited or no authentication, by using either anonymous or simple authentication. LDAP allows for anonymous clients to send LDAP requests to the server without first performing the bind oper- ation. Although anonymous connections don’t require a password, simple authentication will send a person’s password over the network unencrypted. To secure LDAP, anonymous clients should be limited or not used, ensuring that only those with proper credentials are allowed access to the informa- tion. Optionally, the connection can use TLS to secure the connection and protect any data transmitted between the client and server. LDAP can also be used over SSL, which extends security into the Inter- net. LDAPS is Secure LDAP, which encrypts LDAP connections by using SSL or TLS. Some of these types of services integrate as objects, such as Public Key Infrastructure (PKI) certificates, in the authentication process Network Access Security 453 using Smart Card technologies and in the extended properties of account objects so that they can support extra security requirements. To use SSL with LDAP, the LDAP server must have an X.509 server certificate. In addi- tion, SSL/TLS must be enabled on the server. Another issue that can impact the security of LDAP is packet sniffing. As we discussed earlier in this chapter, packet sniffers are software that can capture packets of data from a network and allow a person to view its con- tents. If the information traveling over LDAP is unencrypted, the packets of data could be captured and analysis of the packets could provide consider- able information about the network. In addition to using encryption, ports can be blocked to prevent access from the Internet. LDAP uses TCP/UDP port 389 and LDAP over SSL (LDAPS) uses port 636. By blocking these ports from the Internet, it will prevent those outside of the internal network from listening or making connections to these ports. The challenge with using a protocol such as LDAP is that the connectivity must be facilitated through a script or program. These types of scripts must indicate the location of the objects within the directory service to access them. If the administrator wants to write a quick, simple script, this means that the name of the directory service and the names and locations of the objects that are being accessed must each be placed in the script and known prior to the script being written. If they need to access a different object, they usually need to rewrite the script or develop a much more complex program to integrate the directory services. Even so, compare scripting to native access with queries and interactive responses, and the value of a homogenous net- work with a single directory service is revealed. In a homogenous network, there is no need to logically connect two directory services with a script. This greatly reduces the time and effort involved in administering the network. Homogenous networks are unusual at best. With multiple types of net- work OSs, desktop OSs, and infrastructure OSs available today, it is likely that there will be multiple systems around. It follows that they all must be managed in different ways. LDAP-enabled Web servers can handle authentication centrally, using the LDAP directory. This means users will only need a single login name and password for accessing all resources that use the directory. Users ben- efit from SSO to allow access to any Web server using the directory, or any password-protected Web page or site that uses the directory. The LDAP server constitutes a security realm, which is used to authenticate users. Another advantage of LDAP security for Web-based services is that access control can be enforced based on rules that are defined in the LDAP directory instead of the administrator having to individually configure the OS on each Web server. ChApTEr 9: Security Standards and Services 454 There are security programs available, such as PortalXpert Security, which can be used with LDAP to extend enforcement of the security policies that are defined by the LDAP directory to Web servers that are not LDAP enabled and provide role-based management of access controls. PAP PAP is the simplest form of authentication for a remote access. This method was used earlier to authenticate users using username and passwords. User provides username and passwords for authentication, which is received by the access server, and upon successful validation, the server sends an ack for acknowledgement or a nack for failed authentication. This method is also known as a two-way handshake. PAP transmits the username and password in ASCII without any encryp- tion. PAP was replaced with CHAP to provide more security. CHAP One of the methods that can be used to protect information when using remote access to a resource is the CHAP. CHAP is a remote access authenti- cation protocol used in conjunction with PPP to provide security and authen- tication to users of remote resources. You will recall that PPP replaced the older Serial Line Internet Protocol (SLIP). PPP not only allows for more secu- rity than SLIP but also does not require static addressing to be defined for communication. PPP allows users to use dynamic addressing and multiple protocols during communication with a remote host. CHAP is described in RFC 1994, available at www.ietf.org/rfc/rfc1994.txt?number=1994. The RFC describes a process of authentication that works in the following manner: CHAP is used to periodically verify the identity of the peer using a three- way handshake. This is done upon initial link establishment and may be repeated anytime after the link has been established. 1. After the link establishment phase is complete, the authenticator sends a “challenge” message to the peer. 2. The peer responds with a value calculated based on an ID value, a random value, and the password using a “one-way hash” function such as MD5. Note For more detailed information about LDAP security issues, see the white paper titled “Introduction to Security of LDAP Directory Services” by Wenling Bao at the SANS Institute Web site at http://www.giac.org/certified_professionals/practicals/gsec/0824.php. Network Access Security 455 3. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged; otherwise the connection should be terminated. 4. At random intervals, the authenticator sends a new challenge to the peer and repeats steps one to three. CHAP operates in conjunction with PPP to provide protection of the credentials presented for authentication and to verify connection to a valid resource. It does not operate with encrypted password databases, and there- fore is not as strong a protection as other levels of authentication. The shared secrets may be stored on both ends as a cleartext item, making the secret vulnerable to compromise or detection. CHAP may also be config- ured to store a password using one-way reversible encryption, which uses the one-way hash noted earlier. This provides protection to the password because the hash must match the client wishing to authenticate with the server that has stored the password with the hash value. CHAP is better than PAP, however, because PAP sends passwords across the network in cleartext. TACACS/TACACS+ RADIUS is not the only centralized RAS. TACACS is also used in authenti- cating remote users. TACACS has gone through three major “generations,” TACACS, XTACACS, and TACACS+. TACACS As stated previously, TACACS is the “old man” of centralized remote access authentication. TACACS was first developed during the days of ARPANet, which was the basis for the Internet. TACACS is detailed in RFC 1492, which can be found at http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1492.html. Although TACACS offers authentication and authorization, it does not offer any accounting tools. As mentioned earlier, a good RAS must fit all the criteria of the AAA model. Similar to RADIUS, a dial-up user connects to a RAS that prompts the user for their credentials. The credentials are then passed to the TACACS server, which either permits or denies access to the network. TACACS+ Cisco has developed a proprietary version of TACACS known as TACACS+. The driving factor behind TACACS+ was to offer networking profession- als the ability to manage all remote access components from a centralized . in a Kerberos Realm. FIGurE 9.16 Resource Access in Kerberos Realms. Network Access Security 447 of replay or spoofing of credentials. Replay is the capture of information, modification of the. like logon hour restrictions, which are defined in the origi- nal access token. TGT tickets are not part of the default five-minute period, rather they are cached locally on the machine and are valid. The information on a user alone may include their user- name, password, first name, last name, department, phone number and extension, e-mail address, and a slew of other attributes that are related