Discussed in this chapter are remote access options and alternatives, including traditional remote access and virtual private networking (VPN) architectures.
Remote access can be defined as providing access to fixed site resources to those users who are not at a fixed workstation at that location's local-area network (LAN). Remote access connectivity can be provided via the plain old telephone system (POTS), leased lines, T\_carriers, fractional-T1 systems, X.25 (public switched data network, or PSDN system), Integrated Services Digital Network (ISDN), or Frame Relay system. Traditional remote access systems involve users dialing into a dedicated modem pool, maintained either by a corporate IS/IT staff, or by an IntereXchange Carrier (IXC), such as AT&T, MCIWorldCom, or Sprint. Some IXC offerings involve users dialing into IXC maintained modem pools, and then traversing a dedicated path to a client's office. (Not all IXC carriers offer this option). Traditional modem-pool remote access options can be costly. As the number of remote access users grow, so must the number of modems in the modem-pool, access lines, and long-distance or 800 number charges. Applications such as Remote Access Server (RAS) or pcAnywhere are supported by these modem-pool access infrastructures.
A cost-effective and secure alternative to traditional remote access is Virtual Private Networking (VPN). With VPNs, all phone calls that access corporate networks are local calls tunneled from the remote site to a local Internet service provider (ISP), over the Internet, and to the corporate VPN gateway.
A VPN session is an authenticated and encrypted communications channel, or tunnel, across some form of public network, such as the Internet. Because the network is considered insecure, encryption and authentication are used to protect the data while it is in transit. Typically, a VPN service is independent, meaning that nearly all client operation is transparent to the user and that all information exchanged between the two hosts (WWW, FTP, e-mail, and so on) is transmitted across the encrypted channel.
Before a VPN is established, each network must verify certain requirements. Each site must be set up with a VPN-capable device (router, firewall, or some other VPN dedicated device) on the network perimeter. Each site must know the IP addressing scheme (host, network, and network mask) in use by the other side of the intended connection. Both ends of the tunnel must agree on the authentication method, and if required, exchange digital certificates. Both sides must also agree on the encryption method and exchange the keys required.
VPNs are frequently used to replace both dial-in modem pools or dedicated WAN links. A VPN solution for remote dial-in users can dramatically reduce support costs because no phone lines or 800-number charges must be paid. Hardware does not need to be upgraded as new modem standards are released. A VPN solution also offers advantages over a dedicated WAN environment when most sites are geographically diverse or mobile, saving the cost of dedicated facilities and hardware.
VPNs provide security, at the cost of additional overhead, to what would otherwise be an insecure connection through a private network. A VPN is basically composed of three technologies that, when used together, form the secure connection. These three technologies are authentication, tunneling, and encryption.
Tunneling is used to encapsulate network protocols (TCP/IP, IPX/SPX, AppleTalk, and NetBEUI) into an IP packet that can travel across the Internet. TCP/IP can travel across the Internet on its own, but then it would not be a part of the tunnel or the VPN.
Before the tunnel can be created, it must be verified that the two endpoints are who they say they are. After these endpoints are authenticated, the tunnel is created and information between the two ends is exchanged. Figure 21-1 illustrates a tunnel established across a network service provider's (NSP's) backbone.
The two protocols in Windows 2000 that are responsible for creating the VPN tunnels are Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP). L2TP is an advancement over the PPTP tunneling protocol, and it uses the IP Security (IPSec) authentication and encryption protocol.
Table 21-1 reflects Microsoft clients and the tunneling protocols they support.
Tunneling protocols do not function without an underlying infrastructure protocol, typically PPP. PPP is one of the most common access protocols in use today and is the default for most desktop operating systems (Windows 2000/NT, 9x).
PPP is actually a suite of standardized protocols, much like TCP/IP, that work together to provide a multitude of services used to establish and maintain point-to-point connections.
PPP provides many features, including encapsulation (tunneling) of data, compression of data, multiplexing (multilink) to combine two or more WAN links, reliability by using the high-level data link control (HDLC) protocol to configure data framing, and network configuration negotiation.
NOTE
PPP functions over several media types, such as copper or fiber-optic facilities.
PPP uses two other protocols, Link Control Protocol (LCP) and Network Control Protocol (NCP), to establish and maintain the point-to-point connections. LCP is primarily used to establish the connection and maintain the link parameters such as frame size. NCP is primarily responsible for negotiating network configuration parameters, such as encapsulation and compression, for the network protocols (AppleTalk, TCP/IP, IPX.SPX, and NetBEUI) on the wide-area network (WAN) link.
PPP was designed to allow remote users to dial into their local ISPs and then tunnel their way to the corporate server, such as a Windows 9x PPTP client tunneling to a PPTP server on the corporate network. PPTP uses the existing infrastructure protocols to allow for dial-up connection, namely PPP. PPTP then takes these PPP packets and encapsulates them inside a generic routing encapsulation (GRE) header. Because of the reliance on PPP, PPTP uses encryption algorithms such as Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) to provide the encryption. PPTP also uses Microsoft point-to-point encryption (MPPE) to provide for encryption. Due to the availability of PPTP on NT stations and the installed user base, PPTP is a VPN protocol. PPTP comes in two configurations: compulsory mode and voluntary mode.
A compulsory mode PPTP session uses the services of an ISP with a PPTP front-end processor. Compulsory modes are made with the help of a network access server (NAS). No PPTP software is needed on the client. Any communication problems in a dial-up connection to the ISP are handled by the PPP protocol; therefore, any troubleshooting on the laptop/desktop would be dial-up networking configurations. Compulsory modes also restrict users from accessing other parts of the Internet.
Voluntary mode is where the clients establish the PPTP connection straight to the PPTP server on the other side of the network to create the tunnel. In this instance, the ISP is out of the picture.
PPTP is a combination of the PPP and TCP/IP protocol suites. PPTP combines the features of PPP such as multiprotocol, user authentication, and privacy with the compression of data packets, and TCP/IP offers the routing capabilities of these packets over the Internet.
PPTP is an RFC draft standard (draft-ietf-pppext-pptp-06.txt). As quoted from the draft, PPTP was meant to be able to encapsulate PPP packets and forward them to their destination.
PPTP can take packets such as IP, IPX, NetBIOS, and Systems Network Architecture (SNA) and wrap them in a new IP packet for transport. PPTP uses the GRE to transport PPP packets. It uses encryption for encapsulated data and provides for authentication.
PPTP and IPSec can be thought of as the same: You can have an IPSec client establish a secure session to a firewall and create a VPN or have a PPTP client establish a session to the firewall.
PPTP consists of three types of communications:
PPTP connection—. This is just where a client establishes a PPP or ISDN link to its ISP.
PPTP control connection—. Using the Internet, a user creates a PPTP connection to the VPN server and sets up the PPTP tunnel characteristics.
PPTP data tunnel—. The client and server send communications back to each other inside this encrypted tunnel.
A PPTP connection is typically encrypted with either RC4 or Data Encryption Standard (DES) 40-bit encryption schemes, but a 128-bit encryption version can also be obtained if it is kept within the United States.
L2TP promises to replacement replace PPTP as the tunneling protocol of choice. Vendors such as Cisco, Microsoft, 3Com and others support L2TP. L2TP is based on PPTP and the L2F (Layer 2 Forwarding) Protocol. Cisco designed L2F as is a more robust tunneling protocol that supports the encapsulation of many more protocols than PPTP, including AppleTalk and SNA.
L2TP is basically the same as PPTP. L2TP relies on PPP to establish a dial-up connection, but unlike PPTP, it defines its own tunneling protocol. L2TP uses the PPP (PAP and CHAP) for user authentication, and because it is a Layer 2 protocol, it allows for transportation of non-IP protocols.
L2TP merges PPTP (developed by vendors such as Microsoft, Ascend, and 3Com) with L2F (developed by Cisco) as a single standard (draft-ietf-pppext-l2tp-12.txt). These vendors agreed on a new IETF draft specification that they named L2TP.
L2TP is frequently used for dial-up connections because its design is optimized for dial-up connections rather than site-to-site implementations.
An L2TP VPN setup is similar to the PPTP setup. The data packets include the initial PPP communications, and PPP can be used for the encrypted packets. L2TP is media independent, meaning it can be used over Asynchronous Transfer Mode (ATM), Frame Relay, or IP. An L2TP server replaces the PPTP servers, and an L2TP Access Concentrator replaces the ISP PPTP FEP (Front End Processor). The L2TP VPN allows for multiple connections inside the tunnel and assigns a unique Call ID for each session inside the tunnel. Like PPTP, L2TP defines message types: control and data.
The control messages are responsible for such things as setup, teardown, session management, and tunnel status. Control messages are also used to maintain characteristics inside the tunnel, such as maintaining flow control and determining transmission rates and buffering parameters for the PPP packets for individual sessions.
The data messages are the PPP packet without the framing information.
L2TP uses the same modes as PPTP: compulsory and voluntary.
PPTP and L2TP offer software-based compression, which shrinks user packets. Compression techniques also add a layer of encryption, although it is a small amount. L2TP uses two functions: a client-like line server function referred to as LAC (an L2TP access concentrator) and a server-side network server function called LNS.
Cisco Systems developed L2F to be used in combination with PPTP. With the growth of dial-up services and the availability of many different protocols, it was necessary to find a way to create a virtual dial-up scenario, where any of these non-IP protocols could enjoy the benefit of the Internet. Cisco defined the concept of tunneling, meaning encapsulation of non-IP packets. Users make a PPP, SLIP connection to a dial-up ISP provider, and by the use of L2F, connect to their corporate machines. This tunneling takes place at the border points of the Internet, which are routers with tunneling software called tunnel interfaces.
L2F supports the following:
Protocol independence (IPX, SNA)
Authentication (PPP, CHAP, TACACS++)
Address management (assigned by destination)
Dynamic and secure tunnels
Accounting
Media independence (L2F over ATM, Frame Relay, X.25)
Both L2F tunneling and local Internet access
LAN-to-LAN VPN is the next common VPN configuration. The LAN-to-LAN VPN is closely tied to the IPSec standard. Whereas the remote dial-up user VPN uses protocols such as PPTP, L2F, and L2TP, IPSec concentrates on LAN-to-LAN.
In a typical LAN-to-LAN design, not all traffic is encrypted. Two types of communication are possible:
Web server access—. When a user wants to connect to the Web server on another network, it is simply unencrypted HTTP traffic. The VPN device should not encrypt this traffic; it should flow untouched.
VPN server access—. When a user wants to connect to the VPN server on another network, the VPN device should recognize that it is a VPN request and encrypt the packets.
The DES supports 56-bit encryption and can also be used for LAN-to-LAN encryption. DES is the most popular symmetric-key system and cannot be used for export. Symmetric-key systems are simpler and faster, but their main drawback is that the two parties must somehow exchange the key in a secure way. Public-key encryption avoids this problem because the public key can be distributed in a non-secure way, and the private key is never transmitted.
The customer could use DES or Triple-DES (168-bit encryption) to support cryptographic requirements between routers for intranet communication, as long as both cryptographic endpoints are in the United States.
Authentication is the process of positively identifying the entity (user, router, network device) that requires access. This authentication is usually done by means of a cryptographic function.
The primary reason for authentication with VPNs is to have a method of ensuring that the client and server are who they say they are before the VPN session is established.
Throughout the customers' infrastructure, several password-protected servers and applications are likely to exist. Users can have multiple passwords, such as different ones for different servers. Users are always advised never to write down their passwords or tell anyone else. However, if these users are like the rest of the general computing population, they do one of two things: write it down anyway or choose a password that is easy to recall.
This is the inherent problem with password protection and one of the reasons that passwords are easily guessed. One such attack on this type of security is called a “dictionary attack,” a simple guessing type of attack. These attacks continue to be successful. User authentication scenarios, sometimes described as 2-factor or 3-factor authentication, eliminate this type of guessing attack.
PAP is actually a misnomer because it is the most insecure authentication method available today. Both the username and password are sent across the link in clear text. Anyone snooping the connection could easily grab and use the information to gain access to the network. As a result, using PAP for authentication is not advisable.
The PPTP uses GRE (Microsoft Generic Routing Encapsulation) to tunnel PPP. It adds a connections setup and control protocol.
The PPTP authentication implementation supports three types of user authentication. The two that are concerned with security are the hashed method and challenge response method. Hashed password authentication is based on two one-way hashing functions. During the first hashing function, all passwords entered are converted to uppercase, which reduces the data space. Second, the hashing functions produce the same hash output, given the same password. Unfortunately, no salt or added bits are added to the hashed output, which eliminate duplicate hash outputs from the same hash input. In this authentication model, PPTP is open to dictionary attacks. Additionally, both hash outputs are sent together in the communications string. An attacker can attack the first hash function to compromise the second hash function.
The second security authentication method uses CHAP. CHAP works by the client contacting the server and the server sending back a challenge. The client then performs a hash function, adds some extra information, and sends this back to the server. The server looks in its own database and computes the hash with the challenge. If they are the same, authentication succeeds. Although this method eliminates the dictionary attack, the hashing functions could still be attacked. CHAP also supports the (user transparent) periodic challenge of the client username/password during the session to protect against wire-tapping.
The PPTP framework calls for MPPE, in which the encryption is based on the user's password. After the initial communication is set up, only certain PPP packets are encrypted.
Microsoft Windows 2000 supports three versions of CHAP:
CHAP, an industry standard, is a challenge-response authentication protocol that supports one-way encryption of responses to challenges. The authentication process uses three steps to completion. First, the server challenges the client to prove its identity. Then the client sends an encrypted CHAP message in response to the challenge. The server then verifies the response, and if it is correct, grants the client access.
MS-CHAP is a modified, proprietary version of CHAP. The major difference between MS-CHAP and CHAP in Windows 2000 is that the user's password is in a reversibly encrypted form in MS-CHAP.
MS-CHAPv2 is a stronger, more secure authentication method than previous implementations. It no longer supports Microsoft NT LAN Manager, or NTLM (it can be used only with Windows 2000), it provides mutual authentication, and its separate cryptographic keys are used to send and receive data.
Digital certificates include information about the owner of the certificate; therefore, when users visit the (secured) Web site, their Web browser check information on the certificate to see if it matches the site information included in the URL. A digital certificate could be likened to a “security” driver's license. Sometimes a box appears warning that someone might be trying to intercept your communications. This could be true; however, the problem usually is more likely that the site name is incorrect or the domain name is wrong.
Certificates are issued by Certificate Authorities (CAs) and are priced differently depending on the type of certificate required. Some of the certificates available are as follows:
Class A, 1, Premium, High. These are digital certificates with high-level assurance. Usually used for SSL and SOCKS-enabled sites, they offer high-level security for S/MIME applications, financial transactions, enhanced e-commerce, and other secure applications.
Class B, 2, Medium, Basic. These are the digital certificates with medium-level assurance. Used for access to SSL-enabled sites, they provide medium-level security for S/MIME applications, enhanced e-commerce, online shopping, newspapers, and so on.
Class C, 3, Basic, Freemail. These are the digital certificates with basic security. Used for simple electronic ordering and personal secure mail.
Class D or 4 (chained). This type is used for multipurpose organizations, very much like a multi-user license.
The reason that different names exist is because different CAs name their certificates differently, and some overlap.
Pricing for certificates varies considerably. Variables include the CA and the certificate type requested. Pricing ranges from free to $175 to $200 each, with most CAs offering price breaks for volume.
CAs are actual third-party companies, not concepts or software algorithms. This means that CAs can be broken into and hacked just like any other site. The stronger the CA infrastructure, the stronger the protection that is assured.
The contents of a digital certificate are as follows:
The certificate holder's identity
The certificate's serial number
A valid, unchangeable date for the transaction
The certificate's expiration dates
A copy of the certificate holder's public key for encryption or signature
The group name
The city and state
Digital certificates are based on the International Telecommunications Union, Series X recommendations, ITUX.509 standards, and RSA's “PKCS #7, Cryptographic Message Syntax Standard.”
X.509 digital certificates have been revised to the current proposed version X.509v3. Some modifications to the X.509 standards have been:
With the acceptance of X.509v3 and the public key infrastructure (PKI), businesses are able to conduct business using digital certificates in the PKI framework from their workstations by using a Web-browser and an LDAP-aware application, such as a database.
Some hardware vendors support digital certificates as an IOS feature. This relieves the pressure of each user owning a digital certificate; they “borrow” the certificate from the VPN device when the tunnel connection is made.
Smart cards are similar to credit cards. Smart cards are credit card-sized plastic cards with small chips embedded in them. Smart cards provide data portability, security, and convenience. Three terms used in conjunction with smart cards are as follows:
An IC card with an ISO 7816 interface
A processor IC card
A personal identity token containing IC-s
A smart card is an access control device that supports different applications; it allows users to access personal and business data.
Hardware tokens are tamper-resistant, credit-card sized or smaller devices (a type of smart card) that a user holds in his possession. An LCD on the card consists of six to eight digits, which usually change every 60 seconds. In user-authorization, the LCD is usually combined with a personal identification number (PIN). Only the user knows both the digits and the PIN, and together they serve as the password. For convenience, however, you can limit the password to just the LCD display.
The term software token is just an application on a machine that emulates a hardware token device.
The Public-Key Cryptography Standards (PKCS), developed by RSA in conjunction with a consortium of others, are a set of standards that are being developed for public-key cryptography. PKCS are compatible with the ITU-T X.509 digital certificate standards. The PKCS standard includes some defined algorithm standards such as RSA and Diffie-Hellman. PKCS also defines independent standards that can be used for digital certificates, digital envelopes, and extended digital certificates.
The current list of PKCS standards is available from RSA Laboratories at http://www.rsa.com/rsalabs/pubs/PKCS/.
The Lightweight Directory Access Protocol (LDAP) is an extensible network protocol for accessing information inside a directory. However, the directory structure inside LDAP is not the same as a regular directory. A regular directory usually offers a static view of the contents in that directory—where its contents are created, modified, and deleted over time. An LDAP directory is more dynamic with all types of data that can be stored, such as URLs, certificates, and so on.
LDAP was born out of the X.500 Directory Access Protocol (DAP). X.500 DAP defined a set of protocols in an open system that provided for users and machines to access directory system agents (DSAs), each having a portion of the total directory service in a company.
Some of the LDAP standards define the following:
The network protocol for accessing this information
A namespace defining how information is referenced
How information is organized inside the directory
A distributed model (in LDAPv3)
Remote Authentication Dial-In User Service (RADIUS) is a system of distributed security that secures remote access to networks and network resources against unauthorized access by using the User Datagram Protocol (UDP).
RADIUS authentication includes two components: an authentication server and client protocols. The server is installed on a machine at the customer's site. All user authentication and network service access information is located on the RADIUS server. RADIUS allows for multiple formats that can be suited to an individual customer's requirements. A RADIUS server authenticates users against a UNIX password file, Sun Microsystems Network Information Service (NIS), or in a separately maintained RADIUS database. The RADIUS model works on the client sending authentication requests to the RADIUS server, and acts on acknowledgements sent back by the server.
RADIUS authenticates users through a series of communications between the client and the server.
RADIUS service is not limited to dial-up service. Many firewall vendors support the use of a RADIUS server. Dial-in and VPN users could authenticate using the RADIUS server.
Cisco Systems developed the Terminal Access Controller Access Control System Plus (TACACS+++) protocol. It is a TCP-based access-control protocol using reserved Port 49.
With TACACS+++, when the user attempts to log in, the network access server asks the security server what to do, instead of merely forwarding the name/password to a central server. The security server tells the network access server to initiate a command, such as prompt for the username/password. After the username/password combination has been entered, the security server then sends a permit or denies packet to the NAS.
Encryption is the third major component of a VPN. Encryption is an extra precautionary measure that protects the data through the tunnel. Data is encrypted before it is encapsulated to reduce the risk that someone might tamper with it if the tunnel is breached.
Microsoft Windows 2000 supports two encryption technologies: MPPE and IPSec. Both methods use an encryption key to encrypt and decrypt information at the sender and receiver ends.
Philip Zimmerman's Pretty Good Privacy (PGP) has been used worldwide. PGP is a hybrid cryptosystem, enabling the best of both worlds. It combines both a public-key algorithm and a private-key algorithm. This gives PGP both the speed of a symmetric cryptosystem and the advantages of an asymmetric system. From a user standpoint, PGP acts like any other public-key cryptosystem. PGP uses the Rivest, Shamir, and Adelman (RSA) public-key algorithm and International Data Encryption Algorithm (IDEA) for encryption. A single IDEA key is used to encrypt the message, and the same key is used to decrypt the message (symmetric encryption). Then RSA is used to encrypt the IDEA key used for encryption with the recipient public key (asymmetric). The receiver uses the private key to decrypt the RSA-encrypted IDEA key. Then the decrypted IDEA key is used to decrypt the rest of the message. Along with PGP, Zimmerman created a set of utilities to manage a public key ring, where users can manage multiple keys.
PGP is available free worldwide in versions that run on a variety of platforms, including DOS/Windows, UNIX, and Macintosh. PGP was not developed, nor controlled by, any government or standards organization.
PGP supports the use of digital signatures, message encryption, compression, e-mail compatibility, and segmentation (to accommodate protocol message size limitations).
PKI is a system of digital certificates, certificate authorities (both commercial and governmental), certificate management services, and directory services (LDAP, X.500) that verify the identity and authority of each party involved in any transaction over the Internet. PKI is the framework that provides for privacy and digital signature services in support of international commerce, balancing the needs of government and ensuring privacy.
Currently, several PKI standards are available, including RSA Data Security's PKCS and the digital certificates that X.509 provides. Certificates formats differ: there are X.509 identity certificates, X.509 SET (Secure Electronic Transaction) certificates, PGP signed keys, and SPKI certificates.
Some uses of PKI are for authentication and authorization, privacy and confidentiality, data integrity, and non-repudiation. PKI offers an alternative to plain-text passwords, and supports the client/server requirement for information exchange to be private. PKI offers the ability to protect the tampering of data and offers both the client and server non-repudiation.
Non-repudiation is the ability to prove that one party actually agreed to a transaction. A method must exist to ensure for one party that the other party has indeed sent the message. Without such guarantee, financial house, banking, and sales transactions could not occur. Non-repudiation, in the form of digital signatures, prevents a sending party from “denying” that any transmission actually occurred, hence the guarantee.
Developed by Ron Rivest of RSA Labs, MD5 is a hash function that takes a string of arbitrary length and produces a fixed length output of 128 bits.
The Internet Engineering Task Force (IETF) has a working group called IPSec, which is responsible for defining standards and protocols relating to Internet security. IPSec development efforts came from the Automotive Network Exchange (ANX) requirements. (The goal of the ANX was to connect multiple vendors, suppliers, and customers so that they could exchange data safely). VPNs use these standards as part of their security measures. The IPSec working group is defining the structure of the IP packet and implementing a security association that is used in VPN communications.
IPSec defines protocols for authentication, confidentiality, and data integrity. However, it does not describe access control other than in its packet filtering abilities. This is seen as a major drawback. In addition, the IPSec protocol has not been finalized concerning its key management standards. IP packets have no inherent security. It is relatively easy to forge the source and destination addresses of IP packets, modify the contents of IP packets, replay old packets, and inspect the contents of IP packets in transit. It is not guaranteed that IP datagrams received (1) are from the sender (the source address in the IP header); (2) contain the original data that the sender placed in them; or (3) were not inspected and/or copied by a third party while the packet was in transit. IPSec is a method of protecting IP datagrams. This protection takes the form of data origin authentication, connectionless data integrity authentication, data content confidentiality, anti-replay protection, and limited traffic flow confidentiality.
IPSec is a collection of cryptography-based services and protocols. It provides authentication as well as encryption to a VPN connection that uses L2TP. However, L2TP still uses authentication methods, such as EAP and MS-CHAP.
IPSec currently supports Simple Key Management for Internet Protocol (SKIP) and Internet Security Association Key Management Protocol (ISAKMP). Yet another drawback of IPSec is that it is not compliant with IPv4, so it requires the use of IPv6. This incompatibility is causing much discussion among IETF officials, resulting in the delay with the release of the protocol.
IPSec states that before any communication can take place, a security association (SA) is negotiated between the two VPN nodes or gateways. The SA sets up all the information needed to ensure secure communications. Aspects such as transport and application layer services, authentication, and payload encryption are set up during this SA communication. The SA is responsible for setting up several items in establishing the future secure communication between end hosts, including whether the packet is encrypted, authenticated, or both. IPSec specifies both the endpoint encryption and authentication protocols, such as DES for encryption and MD5 for authentication.
The basic function of IPSec is to encapsulate packets in two optional headers. The authentication header supports authentication and data integrity while the encapsulating security payload ensures privacy. These two headers can be used separately or together, but, for most applications, one header is sufficient.
IPSec provides two modes of operation: transport and tunneled. In transport mode, IPSec encrypts only the IP payload, not the original IP headers. In tunneled mode, the entire packet is encrypted and encapsulated in a new IP packet, which results in significant overhead, but is highly secure.
IPSec has a few problems associated with it. One is that the keys are static; over the duration of the communication, no mechanism allows for exchanging these keys. Scalability has also been hard with IPSec due to the difficulty in managing enormous amounts of encryption keys in large networks. The Certificate Enrollment Protocol (CEP), developed by Cisco Systems and VeriSign, has described a specific way of communicating with a CA to allow the exchange of keys for large numbers of keys.
Another problem with the encapsulation approach of IPSec is that it makes each IP packet bigger after the encryption process takes place. On some LANs, the MTU size would force the fragmentation of these packets, which would increase the network burden network devices, such as routers. The other alternative is encrypting tunnels. Encrypt in Place, for instance, does not increase the size of the packet, but the trade-off is that most tunnels are proprietary. That means that vendor interoperation might be difficult to implement if not impossible.
IPSec does not currently support dynamic addressing. This is one of the many changes proposed to the original IPSec standard. With dial-up users, IPSec needs to know how to handle dynamic addresses within the tunnel.
IPSec provides an IP-only tunnel (not multiprotocol without L2TP or PPTP) or straight IP connection between two endpoints.
Despite these issues and challenges, IPSec is projected to be the standard for future VPN solutions because it combines several security technologies to provide the complete system:
Diffie-Hellman key-exchange is used for deriving key material between peers on a public network.
Public-key cryptography is used for signing the Diffie-Hellman exchanges to guarantee the identity of the two parties.
Encryption algorithms, such as DES, Triple DES, and IDEA, are used for the encryption of the data.
Keyed hash algorithms, such as HMAC, combined with traditional hash algorithms such as MD5 or SHA, are used to provide packet authentication.
Digital certificates signed by a certificate authority allow the exchange of keys for large numbers of keys.
IKE is a good general-purpose security exchange protocol. It can be used for policy negotiation and establishment of authenticated keying material for a variety of needs. The specification of what IKE is being used for is done in a domain of interpretation (DOI). The IPSec DOI exists in RFC2407, which defines how IKE negotiates IPSec SA.
Security associations are used with IPSec to define the processing done on a specific IP packet.
Customers usually evaluate multiple vendor product suites. The National Information Assurance Partnership (NIAP) between the National Institute of Standards and Technology (NSIT) and the National Security Agency (NSA) has established a common criteria evaluation methodology for the testing and evaluation of vendors' firewall products. The focus of this evaluation is to establish an evaluation assurance level (EAL) that can be used to measure the products' IT security assurances.
IT security is defined as the protection of information from unauthorized disclosure, modification, or loss of use by countering threats to that information arising from human or systems-generated activities, malicious or otherwise. Countering threats to an IT product and mitigating risk helps to protect the confidentiality and integrity of information and ensure its availability.
The Common Criteria Scheme overcomes the limitations of the customer having to test each product directly and enables the customer to obtain an impartial assessment of an IT product by an independent entity. This impartial assessment, or security evaluation, includes an analysis of the IT product and the testing of the product for conformance to a set of security requirements. The specific IT product being evaluated is referred to as the target of evaluation (TOE). The security requirements for that product are described in its security target (ST). IT security evaluations are composed of analysis and testing, distinguishing these activities from the more traditional forms of conformance testing in other areas.
The common criteria (CC) document, also known as ISO 15408, combines the best features of three sets of heavy-duty international guidelines for effective network security. The CC provides a common language and structure to express IT security requirements. Using the CC framework, users and developers of IT security products create protection profiles (PPs). PPs are implementation-independent collections of objectives and requirements that a given category of products or systems must meet (as with VPN gateways and firewalls). PPs are used to support defining functional standards; they aid in specifying needs for procurement purposes.
PPs serve as a generic description of product and environment requirements; TOEs are specific products or systems that are evaluated against an existing PP. The sets of evidence about a TOE and the TOE itself form the inputs to an ST.
Security requirements come in two forms: functional and assurance. Functional requirements describe what a product needs to do. Assurance requirements describe how well it meets the functional requirements.
As cited from ISO 15408, a PP is a vigorous overview of a potential candidates system. PPs are organized as follows:
Introduction provides the descriptive information needed to identify, catalog, register, and cross-reference the PP. The overview provides a summary of the PP as a narrative.
TOE clarifies the TOE's security requirements. It also provides a context for the evaluation by addressing the product type and general features of the TOE.
Security environment consists of three subsections that describe and specify the security aspects of the environment in which the TOE is used.
Assumptions about the system include intended usage, aspects of the intended applications, potential asset value, and possible limitations of use.
Threats that require specific protection within the TOE or its environment.
Organizational security policies that govern the TOE or its operating environment.
Security objectives address all aspects of the security environment, as identified in earlier sections of the PP. These objectives define the intent of the TOE to counter identified threats, conform to the organizational security policies, and meet the assumptions.
Security requirements describe what supporting evidence is needed to satisfy security objectives, whether for the TOE or its environment. Two types of requirements are relevant here:
Functional requirements stating what the system has to do to actually fulfill its mission.
Assurance requirements stated as one of the evaluation assurance levels (EALs) from the CC Part III assurance components.
Rationale presents the evidence used by a PP evaluation. This evidence supports the claims that the PP is a complete and cohesive set of requirements and that a compliant TOE provides an effective set of IT security countermeasures within the security environment.
Assurance levels define a scale for measuring the criteria contained in PPs and STs. EALs provide an increasing scale that balances the levels of assurance claimed with the cost and feasibility of acquiring such assurance.
Seven EAL levels exist, ranging from EAL1 (Minimal Protection) to EAL7 (Verified Design).
EAL levels 1 to 4 are considered adequate for most commercially available security devices and systems.
EAL levels 5 to 7 are for government agencies that might need additional assurances that the equipment they have procured or developed actually meets tighter security requirements than would otherwise normally be found in the marketplace.
EAL1, corresponding to Orange Book Criteria Assurance Level D (Minimal Protection), applies where some confidence in correct operation is required, but the threats to security are not considered serious. If independent assurance is required to support a contention that due care has been exercised in protecting personal or similar sensitive information, EAL1 often fits the bill.
EAL2, corresponding to Orange Book Criteria Assurance Level C1 (Discretionary Security Protection), requires the cooperation of the developer so that design information and test results can be obtained, but no further effort is demanded from the developer than is consistent with good commercial practice. EAL2 is applicable where developers or users require independently assured security at a low-to-moderate level, in case the complete development record is not readily available. Such a situation can arise when trying to secure a legacy system (the original documentation might have been discarded), or where access to the developer might be limited.
EAL3, corresponding to Orange Book Criteria Assurance Level C2 (Controlled Access Protection), permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage—without substantial alteration to existing development practices. EAL3 applies when developers or users require a moderate level of independently assured security.
EAL4, corresponding to Orange Book Criteria Assurance Level B1 (Labeled Security Protection), allows a developer to gain maximum assurance from positive security engineering that is based on good commercial development practices. EAL4 is applicable in circumstances where developers or users require a moderate-to-high level of independently assured security in conventional, off-the-shelf products.
For a customer office to establish a VPN tunnel, a connection must first be made to the Internet. This Internet access can be to a local or national ISP. The decision of which to use should be based on individual user and site requirements. If a user is known to travel, an ISP that supports national “local” number dialing should be chosen. A fixed location can benefit from dedicated ISP access, such as ISDN, DSL, or cable modem.
The newer broadband access methods, such as DSL and cable modems, do not currently have ubiquitous coverage in the U.S. It is highly recommended that each site manager verify service availability prior to implementation planning and equipment procurement.
The POTS network is the most familiar communication system in use today. The public switched telephone network (PSTN) is made up of millions of telephone lines in the United States, and various switching systems that connect the voice and data calls. The POTS/PSTN was designed to provide an extremely high level of reliability.
Because POTS was designed for voice communications, it is limited on the rate at which data can be transmitted.
Modems convert digital links to analog signals to be transmitted across the communications link, and convert these signals back again to digital so that the computer can understand them. Modems are categorized by the standards they support—such as V.32, V.32bis, and V.90—and the speed at which they send and receive data. Modems can operate at speeds up to 56 kbps using the V.90 modulation standard. However, the Federal Communication Commission (FCC) power rules limit the ability to send data faster than 33.6 kbps and receive data at 53.3 kbps. The conversion, along with other factors such as noise that are inherent to POTS, chokes the amount of data that can be sent and received over the connection.
ISDN is a digital version of the telephone system (POTS). It can transfer data at a rate much higher than the analog phone system because the line is much cleaner (higher clarity, less noise, and so on).
ISDN is an all-digital transmission facility that is designed to replace the analog PSTN on a worldwide basis. ISDN service is available in two forms: BRI and PRI. Basic Rate Interface (BRI), sometimes represented as 2B + D, operates at 144 kbps. Each (B)earer channel operates at 64 kbps, and the (D)ata channel operates at 16 kbps. Primary Rate Interface (PRI), sometimes represented as 23B + D, operates at 1.536 Mbps.
A cable modem is a modem designed to operate over cable TV lines. Because the coaxial cable used by cable TV provides much greater bandwidth than telephone lines, a cable modem can be used to achieve extremely fast access to the Internet. This, combined with the fact that millions of homes are already wired for cable TV, has made the cable modem something of a holy grail for Internet and cable TV companies.
The cable modem has a number of technical difficulties. One is that the cable TV infrastructure is designed to broadcast TV signals in just one direction—from the cable TV company to people's homes. The Internet, however, is a two-way system where data also needs to flow from the client to the server. In addition, it is still unknown whether the cable TV networks can handle the traffic that would ensue if millions of users began using the system for Internet access.
Cable modem implementations are treated like 10/100-BaseT (Ethernet) LANs. A PC connected via cable modem is on a shared Ethernet segment with other homes/offices. A PC connected via cable modem must meet minimum system and hardware requirements, including support for an Ethernet LAN card. Cable modems act as transparent Ethernet bridges connecting to an NSP. Cable modems modulate data into an analog signal (QAM, QPSK) and perform both frequency-division multiplexing (FDM) and time-division multiplexing (TDM).
Despite these problems, cable modems that offer speeds up to 2 Mbps are already available in many areas. The bandwidth speeds supported by cable modems are dependent on many factors: available bandwidth in the FDM network, number of active users, and usage.
Digital subscriber line is a digital WAN technology that brings high-speed digital networking to homes and businesses over POTS. DSL has many types, including high-speed DSL (HDSL), very high bit-rate DSL (VDSL), and asymmetric DSL (ADSL). ADSL is the most common application because the uplink and downlink bandwidths are not symmetrical, meaning they are not of the same link speed.
ADSL provides high-speed data connections using the same copper phone lines that are used in POTS.
Although ADSL promises high bandwidth, the upstream is slower than the downstream data rate. Typically, the upstream transfer rate ranges from 64 kbps to 256 kbps, whereas downstream rates approach 1.544 Mbps.
Microsoft Windows 9x/NT/2000/XP can support ADSL connections with the installation of a DSL modem/adapter. When an ADSL network adapter is installed in Windows 2000, the adapter appears as either an Ethernet or dial-up interface. If ADSL appears as an Ethernet interface, the connection operates just as it would with an Ethernet connection, but if it appears as a dial-up interface, ADSL uses ATM.
When a customer is too far (beyond 18,000 feet) from an LEC central office (CO), DSL or single-line digital subscriber line (SDSL) offerings are usually deployed. IDSL is essentially the DSL “flavor” of ISDN-BRI, offering 144 kbps of bandwidth. Table 21-2 details the available bandwidth as determined by the distance from the CO.
The following discussion focuses on the policy and administration management of an enterprise organization, including discussions regarding security policies and key management.
At any time in client/server architecture, different applications are running on different servers that support different clients on different networks. If a security application is upgraded or modified, it can affect the entire organization, and it might take days for the IT department to isolate the cause of trouble.
Some vendors support a centralized management feature in their VPN products. This is both a strong security feature and a great troubleshooting mechanism. For example, multiple sites are connected to the Internet and are protected by a firewall/VPN combination or some other VPN device. A central security manager can resolve any problems that might arise connecting an application from a client machine in one department to a server in another department through the VPN. The difficulties arise when trying to get multiple IT staffs involved and coordinating some sort of troubleshooting process to resolve the issue in a timely manner.
Some vendors support the total outsourcing of VPN network security management. This is especially beneficial to those users where maintaining IT infrastructure is not considered a core competency, much less maintaining a security infrastructure. If outsourcing security management is considered, at a minimum, certain requirements should be met.
These minimum requirements include the following:
The vendor should make centralized security management available. This prevents the multiple database updates from being managed, which could lead to inconsistencies in the security platform.
The security management platform of the vendor should be scalable to support multiple thousands of users and change requests.
The vendor should be able to support user administration, authentication, password synchronization, and access control across the entire enterprise network (LAN and WAN).
The vendor should be in a position that it can enforce customer's security standards, policies, and practices. Some vendors can also assist in drafting these security documents.
The vendor should maintain defined backup/restore procedures as agreed upon between the customer and the central security manager.
Sometimes even though a solution to a particular issue works on paper, it does not work in application. When one solution is tried and does not work, another solution is tried. Then it is decided to contact the vendor, so a meeting with the vendor and the entire original IT staff working the issue is called. This process continues on and on, and each time meetings need to be arranged with several people to try to correct one issue. The IT staff, vendor, and possibly users are trying to troubleshoot over the telephone, which can lead to further confusion and time delays due to miscommunication or misinterpretation of the original problem.
A centralized security management process can eliminate these coordination issues. Only the end user and the VPN technician need to be online, and by monitoring both VPN ends, the issue can easily be isolated.
This centralized management feature greatly simplifies the maintenance and troubleshooting processes of the VPN infrastructure. Centralized management eliminates the need for multiple diverse IT staffs and lessens the administrative burdens. If a VPN infrastructure is installed without route-management capabilities, another method needs to be figured out to manage these devices. One method is to put a modem on every VPN device's console port. If this route is chosen, it is best to ensure that the modems have encryption software. This prevents someone from accidentally dialing into the modem because encryption modems communicate only with other encryption modems.
Backup and restore procedures are usually designed for servers and user home directories. The keys of a VPN device are what make the VPN technology safe. If the VPN device experiences problems, it is necessary to have backup configurations so that the device can be reinstalled. Other parties with whom the VPN service has been set up know the keys in the VPN device. If the keys cannot be restored, communication with other parties is unable to be reestablished.
A clearly stated security policy document is a valuable tool. If a third-party central security manager is deployed, the customer and this respective third party should jointly draft this policy.
This security policy should clearly state the following:
The basic security approach (optimistic or pessimistic) for the organization and the portions of the network that are exceptions to the rule
Details of all aspects of security, including physical and human security
The access that is required for each employee or group of employees
There are generally two schools of thought with regards to security policy:
That which is not expressly prohibited is permitted.
That which is not expressly permitted is prohibited.
Windows NT includes several options called policies that are configurable for basic rules to secure the network. The Account Policy dialog box includes options for password requirements, minimum password length, and other items related to user accounts. The policy documentation for an organization should include values for each of the policy options for Windows NT.
Many organizations implement their rule-based firewall policy in accordance with the second item—that which is not expressly permitted is prohibited. The first item, although flexible, can be a security risk to implement. The second item is a secure way to implement a rule policy that continues to allow users to access the Internet.
Any user needs only a standard set of network services to conduct his work: SMTP, HTTP, HTTPS, NNTP, and DNS. These five services cover 90 to 95 percent of necessary user access; any other necessary services can be added for individuals and restricted to specific workstations.
Additional services such as Internet Relay Chat (IRC), Telnet, Trivial File Transfer Protocol (TFTP), and File Transfer Protocol (FTP) can be added on an as-needed basis and restricted to certain individuals who need them.
A firewall or other network boundary device is designed to block all incoming traffic. By allowing incoming services to pass through the firewall, the basic design is circumvented. However, if these incoming services are not allowed, users are unable to perform day-to-day, mission-critical tasks. Creating these holes in the firewall is a necessity, but it is a necessity that needs to be carefully managed and maintained. This approach can be further refined with a demilitarized zone (DMZ). The requested services are first directed to a DMZ, which in turn directs traffic internally.
Figure 21-3 illustrates a good policy to implement. Any traffic coming in from the Internet is first routed to a DMZ. This accomplishes two things. First, it allows an organization to direct traffic to the DMZ, and only that traffic that is necessary is then redirected to the internal networks. Second, this process allows all incoming traffic to be examined first, by placing antivirus software on the DMZ servers; the packets can be examined first and cleaned if necessary. Because of the processing power required, a separate server for this function can be decided upon.
In any of the ISP VPN offerings or in any of the VPN architectures, key safety is an important issue. Just as any backup/restore procedure should be maintained, so must the VPN keys be part of a routine procedure. This is not the generation and management of keys, but where to get them if duplicates are needed. In all VPN architectures, the keys that are generated and managed must be stored in a safe, secure place, not only for security purposes but also for recovery of those keys. These include the public keys, device keys, and any certificates that are published. The encryption keys for the tunnel must also be able to be reproduced in case the VPN device fails and a replacement is needed. The old keys and certificates are still available on the server. This is important because the original keys are needed for revocation.
The following sections discuss network requirements for a VPN implementation.
The following remote access VPN network architectures are discussed:
Firewall based
“Black-box” based
Router based
Remote-access based
The most popular VPN solution is firewall integration. It is a safe assumption that a firewall is placed at the network perimeter; therefore, it is a natural extension to let this device support the VPN connections as well. This provides a central point of management as well as direct cohesion between firewall security policy and traffic let through the tunnel.
A drawback to this method is performance. A busy Internet circuit with multiple VPNs (running strong encryption on each tunnel) could overload the system if all these services are consolidated on a single box. Some firewalls, such as Firewall-1, do support encryption cards to reduce processor load. The encryption card fits in a standard PCI expansion slot and takes care of all traffic encryption and decryption.
Firewall-based VPNs are probably the most common form of VPN implementation today (see Figure 21-4). Many vendors offer firewall-based VPN solutions, each also including its proprietary encryption technology.
Regardless of the vendor hardware/software package used, a VPN standard must still be chosen; PPTP, L2TP, and the IPSec standard are currently being developed. IPSec is a framework so that DES encryption can be used in an IPSec setting.
VPN technology runs on the lower levels of the Open System Interconnection (OSI) stack. A proxy server runs at Layer 7, the application layer of the OSI model, and the packet filtering firewall must examine the complete packet every time it goes by. A stateful-inspection firewall runs at Layers 2 and 3. Because of the processing requirement, VPN technology should only be added to a stateful-inspection firewall.
In the black-box scenario, a vendor offers exactly that—a black box. A black box is a device that is loaded with encryption software to create a VPN tunnel. Some black boxes come with software that runs on a desktop client to help manage that device, and some can be configured via a Web browser. It is generally believed that these hardware encryption devices are faster than the software types. The hardware devices create faster tunnels on demand and perform encryption processes more quickly. However, not all offer or support centralized management or logging. In this scenario, logs need to be sent to external databases for queries. Another server is needed if authentication is a requirement.
Vendors should be supporting all three tunneling protocols (PPTP, L2TP, and IPSec). However, specific vendors need to be thoroughly researched.
The black box VPN sits behind a firewall. It can, however, sit on the side of the firewall. The firewall provides security to the organization, not to the data. Likewise, the VPN device provides security to the data, but not the organization.
Figure 21-5 illustrates a typical black box VPN implementation.
The firewall is in front of the VPN device, and most likely, a rule-based policy on the firewall needs to be installed. In the firewall configuration, ensure that encrypted packets can be passed. The firewall is there for protection. If the firewall is filtering on the TCP ports and the packets come in encrypted, the firewall tries to examine the packet, realizes it cannot, and drops the packet.
Router-based VPNs are possible for an organization that has a large capital investment in routers and an experienced IT staff. Many router vendors support this configuration. Two types of router-based VPNs exist. The first method is where software is added to the router to allow an encryption process to occur. The second method is where an external card from a third-party vendor is inserted into the router chassis. This method is designed to off-load the encryption process from the router CPU to the additional card.
Some vendors support hot swapping and redundancy, which are built into their router-based VPN products. This is certainly a requirement for organizations that cannot tolerate downtime. It is also worth noting that performance can be an issue with router-based VPNs. Due to the addition of an encryption process to the routing process, a heavier burden can be added to the router CPU. This is especially true if the router is handling a large number of routes or implementing an intensive routing algorithm.
Figure 21-6 represents a typical router-based VPN, where packets are encrypted from source to destination.
The two concerns with router-based VPNs are as follows:
Interoperability—. If a connection to the VPN of a supplier is required, will both the site router and the router of the supplier operate with one another and create the VPN?
Encapsulation—. Will non-IP protocols, such as IPX or SNA, be transported? Some router manufacturers only encrypt; they do not encapsulate.
Terminating the VPN at the border router allows the traffic stream to be decrypted before it reaches the firewall. Although process load is still a concern, many routers now use application-specific integrated circuit (ASIC) hardware. This allows the router to dedicate certain processors for specific tasks, thus preventing any one activity from overloading the router.
The drawback to a router-based VPN is security. Routers are (typically) extremely poor at providing perimeter security compared to the average firewall. It is possible that an attacker would be able to spoof traffic past the router, which the firewall would interpret as originating from the other side of the VPN tunnel. This means that the attacker might be able to gain access to services that are typically not visible from other locations on the Internet.
Remote access, as the term applies, means that a remote user is trying to access the resources of an organization by creating an encrypted packet stream. The term might appropriately apply to the software running on a user's machine, which is trying to create the tunnel to the organization, and to a device on the network allowing the connection. This tunnel could be coming in from the Internet, but it also could be coming in from a dedicated, dial-up, or ISDN line.
Figure 21-7 illustrates a typical remote access VPN implementation.
This scenario reflects software running on remote machines, and those machines establish a connection via an encrypted tunnel to the internal server, or from a dial-up access line, to an authentication server. An access server on the network, router, firewall, black box, or stand-alone authentication server grants the access. This remote access device minimizes the amount of costly leased-line equipment and remote dial-up access equipment.
Common VPN components of any network are as follows:
Gateway devices (routers, dedicated servers, firewalls)
Client software
PKI and associated key management strategies
Hardware-based encryption accelerators
X.509 digital certificates
CAs
A customer-entrusted CA, if utilized, should maintain the digital certificates for that customer. This CA can be internal to the customer or a trusted third-party vendor or security manager.
Directory services
LDAP is the recommended protocol for secure certificate services (that is, certificate storage and lookup).
Servers with load balancing, fail-over, redundancy
VPN gateway product(s) feature requirements:
X.509 digital-certificate support.
LDAP support.
IPSec compliant.
Encryption types supported.
Performance (Mbps) [This is negotiable with a service level agreement, or SLA.]
Maximum number of interfaces.
Maximum number of connections.
Quality of service (QoS) support [This is negotiable with an SLA.]
Clustering support.
Custom-application support.
Support of high-availability (HA) features.
Compliance with EAL/TISEC/TCSEC laws
Network transport
VPN access points are dependent on the ISP used. This should be a factor when choosing an ISP because local access numbers should be available nationwide to support traveling users.
This requirement is relative only when non-IP protocols are being used. Any customer application that is using IPX, AppleTalk, and so on needs to have those protocols tunneled by the VPN client and server.
TCP/IP is the underlying protocol suite for all VPN services. All VPN clients and network devices must be configured to support TCP/IP.
The existing Cisco PIX and Checkpoint FireWall-1 firewalls can support a VPN infrastructure. Some vendor firewalls and clients can exchange keys using IKE, such as Cisco network devices and Cisco PIX firewall. However, inter-vendor options require the firewall to be configured for manual IPSec. Manual IPSec requires the security manager to manually configure the IPSec keys on the firewall. Existing authentication technologies include the following:
UserID/Password only
Hardware or software token support, such as SecureID
PKI support
These applications are typically e-mail services, intranet HTTP services, and possibly batch data transfers.
The bandwidth requirement is determined by three factors:
Number of users at each remote access point
Type and nature of data traffic that is generated/received by each remote access user/site
Frequency of traffic
The VPN server and client must be configured to support the same tunneling protocol, such as IPSec or PPTP.
It is advisable that the customer designates an internal or external organization that can be available on a 24-7 basis to respond to major security issues, such as breaches.
Administrative-related security issues, such as password resets, can be handled on a Monday through Friday, 9 a.m. to 5 p.m. basis.
The VPN architecture needs to scale to meet the anticipated growth that the customer sees in the number of users of the network architecture. As the number of users and required resources grow, the VPN infrastructure—including server farms and access devices—should be reviewed to ensure that maximum network availability is maintained.
This is directly related to the future network plans that the customer has for his network and the related remote access/VPN infrastructure. The critical devices that must be scalable are authentication server(s), database servers, and Web servers.
The customer should publish a standard security document, made available to all users and internetworked vendors. This document should include a basic overview of the security approach supported by the customer, and clearly identify any authorized exceptions. The customer security document should also include details of all security aspects, levels of security authorized for defined user groups, and procedures for users to request changes be made to their security profiles/access rights.
The security policy document should also include VPN management responsibilities, such as the following:
Who administers and enforces the VPN and security systems?
Who performs Registration Authority (RA) activities?
Who administers the desktop systems for the users?
This is important because the systems should be consistent for users across all platforms, including drivers, plug-ins, dynamic link libraries (DLLs), application programs, and any network operating systems (NOS) client components.
Desktop systems are also points of vulnerability and should have up-to-date virus protection installed. Rogue software that could support a security breach needs to be accounted for, and auto-answer modems should be disabled because they allow an intruder with a “wardialer” to penetrate the VPN by “piggybacking” off the machine of a legitimate user.
The following sections address VPN requirements around remote user access requirements.
Remote user-access requirements are simply stated; connect to a local ISP by whatever option is preferred and supported. Access options were previously discussed under the Telecommunications category, but simply revisited, these options are: Analog Dial-up (POTS), ISDN, xDSL, Cable Modem, or dedicated (private) access lines.
It is recommended that a single, nationwide ISP be chosen to provide access services. Most nationwide ISPs support POTS dial-up, ISDN and xDSL. However, sometimes the ISP is unable to support a preferred access method, such as a cable modem. These cases should be handled on an individual basis.
For traveling/mobile users, a nationwide ISP would be preferred because it is almost assured that local access numbers from every major city are available, precluding any additional long-distance charges.
The following sections discuss performance requirements for a VPN implementation.
Cryptographic hardware accelerator support is not a mandated requirement, but any VPN equipment considered for procurement should support this function in support of potential future growth.
The clustering of servers, or a server farm, is important to maintaining near-100 percent availability. If one (or multiple) servers fail or are taken down for maintenance, it should be transparent to the remote office/end user. Server farms are scalable as long as they can share databases. No server should be an “information island.”
QoS is a process whereby switches and routers set up resources to move data quickly and reliably. Often ISPs cannot support true QoS because they do not control the entire connection, including local access and backbone interconnects.
The IETF published a standard called Diff-Serv, which is intended to allow ISPs to deploy different QoS levels on the Internet's backbone. This is accomplished by allowing users to mark data packets so that routers can forward them appropriately.
Diff-Serv has all but replaced Resource Reservation Protocol (RSVP) in an effort to implement QoS. RSVP relied on a type of signaling mechanism between devices on the Internet—specifically routers. This signaling setup was done on a per-connection basis, and it required that all routers on the Internet agree to a specific level of service.
SLAs are contractual agreements between the organization for a user (in this case the customer) and the ISP. Some of the aspects that are spelled out in these contracts are data rates, types of service, and performance statistics. The objective of an SLA is to quantify specific objectives and metrics that are used as a benchmark to ensure adherence to the agreement.
In an SLA, the following three areas should be addressed: network uptime, bandwidth, and latency. The network provider can usually provide some sort of guarantee for network uptime and bandwidth, but latency continues to be a major obstacle for any kind of performance guarantee.
This is the actual time that the network is up and available to pass traffic. It is important to consider both up and pass. The network could be up but unable to pass traffic. For example, if monitoring on the data link level (such as Frame Relay), a device could report as being up, but the network layer (such as IP) of that device—the actual layer that forwards the traffic—could be down.
Bandwidth could mean the bandwidth of the access pipe to the provider, or the available bandwidth over the backbone of the provider. Although most service providers are deploying Synchronous Optical Network (SONET) technology in their backbones, with terabit per second (Tbps) service, the available bandwidth is still only the least of the access pipes on either side of the connection.
In most SLAs, the provider can easily document and verify bandwidth statistics.
Latency is the concept that explains the time delay in setting up the initial communication link between points. A network connection can traverse two, three, or multiple ISP backbones. This makes it difficult for an ISP to guarantee latency between two endpoints because it does not always have control over the middle. Because of this, most ISPs only offer a latency guarantee across their own backbone. This is about the best kind of latency guarantee that can be expected.
The customer should have either hot-standby VPN devices interconnected with the VPN network, or spares that are physically available to meet a 4 hour mean time to repair (MTTR).
As previously discussed, the VPN infrastructure should scale as the number of users, and subsequently the amount of bandwidth required, grows. An ISP's ability to support user-required bandwidth growth within a minimal turnaround time (usually 30 days) should be a factor in the selection process.
The following sections discuss VPN client requirements, guidelines, and vulnerabilities.
The Windows 95 operating system does not fully lend itself to immediate secure communications. Microsoft has issued several patches to resolve security issues within the operating system, related applications, and dial-up networking. The Windows 95 operating system is limited to the FAT file system, which does not include security features. When Windows 95 files are shared across the network, they use a simple password scheme with limited security. The Windows 98 operating system is limited to the FAT or FAT32 file system, which does not include security features. Like Windows 95, when Windows 98 files are shared across the network, they use a simple password scheme with limited security.
Windows 98 can be used for client workstations in a Windows NT network environment with little security risk. This is provided that the users save their files on the server rather than a local hard drive, log out whenever they leave the console, and do not log in as a member of the administrators group over the network.
It is recommended that the customer deploy Windows 98 Second Edition, Windows NT Workstation, or Windows 2000/XP Professional to the remote users of the VPN. These platforms are not immune to security vulnerabilities, but they are more secure than Windows 95 or the first edition of Windows 98. These security vulnerabilities are discussed next.
A good place to start regarding Windows 9x would be at the Microsoft Security Advisor Page at http://www.microsoft.com/security/default.asp. Some general guidelines are listed next:
Do not enable file sharing! Windows 9x does not understand the security behind file security. When logged on to a 9x system, the user is usually asked for a username/password. This is just identification to other machines; it is not intended to protect the machine. What this does is tell everybody on the network that a new user is on the network and that person can read and copy any files on the network. This accessible data could include any public/private keys used for encryption. If others need access to the machine of a specific user, make sure that machine is password protected and restricted to only those necessary resources.
Ensure that virus software is installed and is up to date. Although a virus attack might have no direct impact on VPN security, a virus could attack the PPTP stack, preventing PPTP session establishment with the VPN server.
Windows 9x has a list of known vulnerabilities, along with available patches to correct these problems. These vulnerabilities are most likely to compromise only a local machine, but it is a compromise nonetheless. The following is a list of Windows 9x vulnerabilities:
Back office vulnerability allows a user to remotely manage another machine. It gives the remote user more control than the person sitting at the console. Back office vulnerability can be done over a LAN or the Internet.
The Internet Explorer vulnerability might allow a malicious Web page to crash Internet Explorer and possibly execute arbitrary code on the browser's machine. As certificates are added to the VPN infrastructure, this becomes particularly worrisome. An attacker could use the certificate on the browser for another user, creating a situation of compromised certificates.
Teardrop vulnerability occurs when an attacker sends an overlapping, fragmented IP data stream to the intended victim. Windows 9x cannot handle this, and the system hangs, forcing the need for a reboot to be able to recover. A WinSock 2 update is recommended.
ICMP vulnerability is exploited when an attacker sends a ping packet to the intended victim and specifies in the header an incorrect packet length. The only recourse here is a reboot.
Out-of-band (OOB) vulnerability occurs if IP packets are sent to a Windows 9x machine that has an out-of-band data flag set. A common port is 139, although others can be used. A reboot is needed in this situation to recover.
Windows 9x stores passwords to network resources in a file (designated with a .PWL extension) that is encrypted using an RC4 encryption algorithm. The problem is that the PWL files are too predictable, making a plaintext attack viable, and possibly resulting in the revealing of passwords on the network.
When using the file and print services for the NetWare system, any user who has remote administration software can view files on other hard drives on the network without authorization.
It might be possible to obtain the clear-text Windows 9x login password from a Windows 9x machine on a network connected directly to the Internet. There is vulnerability when using a Samba server on Ports 137 and 139, a malicious Web page, and an NT server that tries to log in with the Windows 9x username/password in clear text.
Like Windows NT, UNIX was plagued with security problems in its early days. UNIX was not really developed with security in mind. In fact, the creators of UNIX initially developed it so that they would have a platform on which to play games.
UNIX is considered more secure than Windows NT because it has been around longer. UNIX was created in 1969 and since then has been the preferred victim for hackers everywhere. Because of this, UNIX developers have rushed to keep up, plugging security holes as hackers find them.
Despite its maturity, UNIX still has security problems. Although it is possible to make an extremely secure UNIX system by carefully configuring features and installing security fixes, many administrators do not have the time or budget to maintain a completely secure system.
A breakdown of security vulnerabilities with UNIX is not discussed here because they are beyond the scope of this customer report.
Although Windows NT was originally intended to replace Windows, it has evolved into a platform for reliable network servers. Although Windows NT was designed with security in mind, it was not widely used for networking at first, and was plagued with security problems. Microsoft has improved its security significantly, but security holes still exist. Nevertheless, it is possible to run a secure system using Windows NT; all it takes are the latest security fixes from Microsoft.
Microsoft publishes updates called “hot fixes” on its Web site at http://support.microsoft.com/support/.
Some guidelines are associated with the implementation of the Windows NT operating system. Windows NT was designed with networking in mind and requires some extra care when deployed in a secure environment. Windows NT can be used as a main server, file server, Web server, application firewall, and PPTP VPN server. The following is a list of guidelines:
Running unneeded networking protocols increases the risk of system break-in. Most organizations need TCP/IP networking, along with NetWare resources. However, it is usually not recommended that the NetBEUI protocol be enabled. It is best to ensure that whatever services are turned on are operationally needed. A common approach taken by many is to shut down everything except the basic ports needed to communicate, and then add them back in one-by-one as necessary (such as TCP Port 25, UDP Port 53). A detailed and continuously updated list of all TCP/UDP ports can be found at http://www.iana.org/assignments/port-numbers.
It is recommended that a false administrator account be set up with minimal or no privileges. The real administrator privileges should then be established using a different account name. Because NT uses the administrator as the super-user, an attacker can try to break into the administrator account. If someone breaks into this account, he will not realize it is a fake one. He will think it is just a dead machine with nothing interesting.
If NetBIOS service is not needed, block ports 137, 138, and 139. By blocking these ports, most attacks can be prevented, including red buttons and OOB data packets that can crash the system.
To prevent against certain types of guessing attacks against passwords, it is a good idea to periodically check that users have chosen strong passwords. L0phtcrack 2.0 is a utility that can be used with password dictionaries to check this (http://www.l0pht.com).
Ensure that virus software is installed and is up to date. Although a virus attack might have no direct impact on VPN security, a virus could attack the PPTP stack, preventing PPTP session establishment with the VPN server.
The Windows NT Resource Kit provides Windows NT the C2 Configuration Manager (C2CONFIG.EXE). This program compares the security of the NT machine configuration against the C2-level security standards of the federal government's National Computer Security Center. It then presents the options required to bring the machine up to C2 standards.
Like Windows 9x and UNIX, Windows NT has its share of vulnerabilities, including the following:
A denial of service can occur if an attacker uses the Windows NT 4 named pipes. The way that NT handles pipes over a remote procedure call (RPC) is the cause of this problem.
The NT ICMP vulnerability is similar to the one in the Windows 9x operating system. A ping packet is sent to the victim, and the packet size does not match the actual size of the packet. A reboot is needed to correct this problem. A fix for this is available from Microsoft.
An attacker can exploit the Internet Explorer vulnerability and use malicious code on a Web page to crash and execute a teardrop denial of service on a machine. By executing this code, the NT machine hangs after receiving corrupted UDP data packets, and a reboot is necessary.
Another vulnerability exists where an attacker can spoof the remote procedure call (RPC) vulnerability and send spoofed RPC datagrams to Port 135 of the victim. The server would then send reject packets to the spoofed machine. This would continue, and a loop would occur. In addition, if multiple machines were targeted, network bandwidth would be wasted.
Windows NT, like Windows 9x, is subject to OOB vulnerability.
Anonymous login vulnerability exists within Windows NT. NT Explorer and ACL use account names for various functions. Explorer uses account names to decide whether to grant access to an object, and the NT ACL uses it to decide whether to grant access rights to specific objects. However, because of this functionality, anonymous logon users can list domain usernames and identify share names. For enhanced security, this functionality should be restricted.
DHCP is supported by the local ISP-dial platform. The client obtains a registered IP address space from the DHCP server upon IP session negotiation. After a registered space is given, the user is then required to initiate a VPN session to the host server to access any protected services.
This VPN session needs to be established with a dedicated customer VPN server. As multiple ISP DHCP servers support the remote client, a username/password scheme is best used here so that authorized users are not inadvertently blocked.
The customer should publish a standard security document, made available to all customer members. This document should include a basic overview of the customer's security approach, and clearly identify any authorized exceptions. The customer security document should also include details of all security aspects, levels of security authorized for defined user groups, and procedures for users to request that changes be made to their security profiles/access rights.
The security policy document should also include VPN management responsibilities:
Who administers and enforces the VPN and security systems?
Who performs RA activities?
Who administers the desktop systems for the users?
This is important because systems should be consistent for all users across all platforms, including drivers, plug-ins, DLLs, application programs, and any NOS client components.
Desktop systems are also points of vulnerability and should have up-to-date virus protection installed. Rogue software that could support a security breach needs to be accounted for, and auto-answer modems should be disabled because they allow an intruder with a “wardialer” to penetrate the VPN by “piggybacking” off the machine of a legitimate user.
This chapter discussed remote access options and alternatives, including traditional remote access and Virtual Private Network (VPN) architectures.
Remote access is defined as providing access to fixed site resources to those users who are not at a fixed workstation at that location's local-area network (LAN).
A cost-effective and secure alternative to traditional remote access is VPN. With VPNs, all phone calls that access corporate networks are local calls tunneled from the remote site to a local Internet service provider (ISP), over the Internet, and to the corporate VPN gateway.
VPN has three major components:
LAN-to-LAN VPN is the next common VPN configuration. The LAN-to-LAN VPN is closely tied to the IPSec standard. Whereas the remote dial-up user VPN uses protocols such as PPTP, L2F, and L2TP, IPSec concentrates on LAN-to-LAN.
Authentication is the process of positively identifying the entity (user, router, network device) that requires access. This authentication is usually done by means of a cryptographic function.
Encryption is an extra precautionary measure that protects the data through the tunnel. Data is encrypted before it is encapsulated to reduce the risk that someone might tamper with it if the tunnel is breached.