Remote Access Technologies
VPN & Tunneling
REMOTE ACCESS TECHNOLOGIES
Almost every company offers some type of remote access to accommodate employees working from home, business partners, or external technical support. Remote access became very popular partly due to the Remote Access Service (RAS) on Microsoft's Windows NT. It allows remote clients to dial-in and connect and logon to network as if they were sitting in the office and locally connected. Nowadays the acronym RAS is used to define many types of remote dial-in solutions. Remote access obviously can be a useful feature, but also provides an entrance an attacker may try to exploit. The early remote access systems using modems were anything but secure. A popular method used by hackers and phreakers to break into remote networks is war dialing. This refers to dialing a list of numbers until a modem picks up and then use brute force dictionary attacks to guess valid username and password credentials. RAS systems often provide a call back feature, which ensures that regardless of the phone number used to call the modem, the modem will hang up and call back a predefined phone number. Another simple security measure against war dialing is configuring the modem to let it ring for 5 times or more before answering, as the tools used for war dialing usually move on to the next number before that.
POINT-TO-POINT PROTOCOL (PPP)
PPP is today's most widely used RAS protocol and is supported by virtually every network system because it is part of the TCP/IP suite. PPP operates at the Network layer of the OSI model. Besides point-to-point dial-up connections over POTS and ISDN, PPP is also used for router-to-router connections in WANs. PPP is the successor of SLIP, an older dial-up protocol, used primarily in UNIX environments and still supported by some ISPs. Major differences with PPP are that SLIP lacks authentication, compression, and multilink capabilities.
PPP supports several authentication protocols including MS-CHAP, EAP, the older Password Authentication Protocol (PAP) and the common Challenge Handshake Authentication Protocol (CHAP). After the remote client is authenticated, the PPP connection is rather insecure because the transmitted data is not encrypted. Several other protocols are available to encrypt the transmitted data and the authentication process. Examples of such protocols are PPTP and IPSec, and are discussed later in this chapter.
RADIUS (Remote Authentication Dial-In User Service)
The Remote Authentication Dial-In User Service (RADIUS) provides authentication to clients that connect to a remote access server by using a SLIP or PPP dialup connection and an authentication protocol such as PAP, CHAP, or EAP. It allows a Network Access Server (NAS), which can be a remote access server, router, or wireless access point for example, to delegate the task of authenticating clients to a centralized RADIUS server. When a user dials in to a remote access server, the remote access server acts as a RADIUS client and forwards the access request to the RADIUS server. The RADIUS server is usually a service running on a Windows or UNIX server and uses its local user database or contacts another server, such as a Windows domain controller or LDAP directory, to authenticate the client’s logon information. If the remote client is successfully authenticated, the RADIUS server replies to the RADIUS client (the NAS), which in turn accepts the connection of the remote client.
In addition to centralized authentication and user management, RADIUS provides centralized authorization, which is the management of access permissions, and accounting, which refers to tracking when and what network resources are accessed by a particular client. The accounting information can in turn be used for auditing. This AAA (Authentication, Authorization, and Accounting) information is exchanged between the NAS and the RADIUS server using the RADIUS protocol in UDP packets. UDP port 1812 is used for the RADIUS authentication protocol and 1813 for the RADIUS accounting protocol.
One of the main vulnerabilities of RADIUS is that even though it encrypts the user’s password before transmitting it between the access server and the RADIUS server, other information, including the username and the authorization details in an access accept packet, is transmitted in clear text. This can be solved by using RADIUS in combination with L2TP or IPSec for example.
TACACS+ (Terminal Access Controller Access Control System+)
Terminal Access Controller Access Control System+ (TACACS+) is Cisco’s enhanced version of TACAC/XTACACS and is developed to provide a more secure alternative to RADIUS. Instead of just encrypting the password as RADIUS does, TACACS+ encrypts the entire access request packet, hence all the authentication information it is kept safe from sniffing attacks. Another main advantage of TACACS+ is that it separates the AAA services, allowing it to work with different protocols and technologies per service. For example, you can use Kerberos to perform the authentication process, and use TACACS+ itself to for authorization and accounting. Another major advantage of using TACACS+ instead of RADIUS is that it used TCP (port 49) instead of UDP.
TACACS+ has several weaknesses such as the lack of integrity checking, vulnerability to replay attacks, and weak session keys for packet encryption. There are different implementations of both RADIUS and TACACS, which each can have their own vulnerabilities, as well as their own solutions to problems inherit to the design. Regardless and just as with RADIUS, additional security protocols should be used to protect the information transmitted between the NAS and the TACACS+ authentication server.
VPN (Virtual Private Network) & Tunneling
A Virtual Private Network (VPN) is a private connection over a public network such as the Internet. VPNs can save a company a lot of money because they can use their Internet connection, instead of expensive long-distance point-to-point connections such as dial-up, ISDN, and leased lines, to allow remote networks and remote employees to connect to the corporate network. The first main type of VPN is a connection between two networks and is known as a site-to-site or LAN-to-LAN VPN. It is typically used for connecting branch offices of a single organization or for creating an extranet for business partners. When the VPN is established, a private virtual point-to-point connection, called a tunnel, is created over the Internet between two routers or firewalls. The clients and servers in the networks on both sides of the VPN connection are unaware of the VPN. The following network diagram shows a simple example of a site-to-site VPN. The green line depicts the virtual connection.
The second main type of VPN, called remote access VPN, is especially useful for remote and mobile users who need to access the corporate network. Whether they are in a hotel, at a business partner’s office, or on a business trip to the other side of the planet, all they need is an Internet connection and a VPN client. The VPN client software is installed on the client operating system and establishes a tunnel to the corporate network after a connection with a local ISP is established. This type of VPN is referred to as remote access VPN and is depicted in the following network diagram. The remote access connection from the client to the Internet can be anything from a dial-up to a cable connection as long as it supports PPP. The router in the following network diagram can be a firewall or a VPN hardware appliance.
Tunneling refers to encapsulating a packet into another packet. There are at least three types of protocols involved in a tunnel. The first is the carrier protocol, for example IP on the public Internet. The second is the tunneling protocol, for example PPTP, L2TP, and IPSec. The third is the encapsulated protocol, such as IP, IPX, NetBEUI and AppleTalk. The following three sections cover the tunneling protocols.
PPTP (Point to Point Tunneling Protocol)
Point to Point Tunneling Protocol (PPTP) is a tunneling protocol creat ed primarily by Microsoft. It is an extension of PPP and encapsulates PPP packets to transfer them through a tunnel over a public IP network. The encapsulated protocol can be IP as well, but also IPX, AppleTalk, and other protocols support ed by PPP. PPTP itself does not provide any real security; it does not encrypt the encapsulated packets, it merely tunnels (encapsulates) them. It sends control data unauthenticated and basically in clear text, making it vulnerable to eavesdropping and hijacking attacks. PPTP relies on the authentication protocols in PPP, such as MS-CHAP, and relies on a protocol called Microsoft Point-to-Point Encryption (MPPE) to provide actual data encryption using a 40-bits or 128-bits RC4 cipher. PPTP operates at the Data-Link layer of the OSI-model and uses TCP port 1723.
L2TP (Layer Two Tunneling Protocol)
The Layer 2 Tunneling Protocol (L2TP) is an IETF standard developed to replace PPTP and is the result of combining the technology of Microsoft’s PPTP with Cisco's Layer 2 Forwarding (L2F) tunneling protocol. In addition to IP networks, L2TP supports tunneling through various other types of point-to-point networks including Frame Relay, X.25, and ATM. L2TP operates at the Data-Link layer of the OSI-model and uses UDP port 1701. The encapsulated protocol can be IP, but also IPX, AppleTalk, and other protocols support ed by PPP (even though they are transmitted as IP packets). Just as with PPTP, L2TP does not actually encrypt data, nor does it authenticate individual messages. To overcome these shortcomings, L2TP is often us ed in conjunction with IPSec. This combination provides an additional layer of authentication and encryption because the L2TP packets are encapsulated in IPSec packets at the Network layer.
IPSec (Internet Protocol Security)
IPSec is a popular and complete encryption framework for IP networks that provides end-to-end security at the Network layer. It provides data confidentiality, data integrity, and authentication of data origin by employing a variety of protocols and encryption techniques. IPSec is often us ed in conjunction with tunneling protocols to offer a higher level of security in VPNs. Besides VPNs, IPSec is also used in LAN environments for client/server connections, router-to-router connections in WANs, and for secure RAS connections. A primary advantage of IPSec is that it is transparent to the user and can be easily implemented because most modern operating systems and network devices support it natively. But at the same time it is also very complex. Before we break down IPSec into its different protocols and operating modes, let us first have a look at how an IPSec connection in general provides confidentiality, integrity, and authentication.
An IPSec connection can be established between a wide variety of network devices including firewalls, routers, clients, and servers. A single device can have a connection with multiple other devices simultaneously. When a new IPSec connection is initiated, the two devices use a handshake process to negotiate which protocols, modes, encryption algorithms, key size, and other communication settings they will use. These settings are stored in a separate Security Association (SA) for each direction, hence two SAs for each communication partner. When a device receives an IPSec packet, it will look at the header information to determine which SA’s settings it should use to interpret the received packet.
One of the main parameters decided on during the handshake process is the protocol IPSec uses to provide security for IP packets. IPSec can employ two protocols main protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP), which can be used separately or in conjunction. AH provides integrity and data origin authentication of IP packets by using a hashing algorithm (MD5 or SHA-1) and a shared secret (symmetric key) to calculate a message digest, also known as integrity check value. The receiving device performs the same calculation and if the resulting value matches, the packet has not changed along the path, meaning data integrity is provided. It also ensures the sending device is indeed the intended communication partner that holds the symmetric key that was exchanged when the SA was created, meaning authentication of data origin is provided. AH can optionally require replay protection, by setting a replay bit in the header.
AH provides integrity, meaning the packet cannot be altered during transport without going unnoticed. However, it does not prevent the packet from being disclosed or altered in the first place. In other words, AH does not provide confidentiality. The latter requires the ESP protocol to be enabled. ESP performs the same authentication and integrity operations as AH, but in addition provides confidentiality. It actually encrypts a packet’s payload (the actual data portion) or the entire packet, thus including the header. If the original header is encrypted, a new header with the basic IP address information is added to the encrypted packet, so routers and network devices can still read the information they need in order to transport the packet. For the actual encryption, the symmetric key exchanged earlier is used with the DES or 3DES algorithm.
ESP use IP protocol ID 50 and AH uses IP protocol ID 51.
Whether the payload or the payload and the header are protected by AH or ESP depends on the mode in which IPSec operates. IPSec can run in two different modes: Transport mode or Tunnel mode. In transport mode, only the payload of an IP packet is protected. In tunnel mode, the payload and the header are protected. The two protocols and two modes allow for the following four main configurations:
- AH in Transport Mode – Provides integrity and data origin authentication for only the payload of an IP packet.
- AH in Tunnel Mode – Provides integrity and data origin authentication for the entire IP packet including the header.
- ESP in Transport Mode – Provides confidentiality for only the payload of an IP packet.
- ESP in Tunnel Mode – Provides confidentiality for the entire IP packet including the header.
The symmetric key used to calculate the message digest, to provide integrity and authentication of data origin, can be pre-shared (manually configured) or dynamically generated and exchanged by an additional protocol. The standard key exchange protocol for IPSec is the Internet Key Exchange (IKE) protocol, which in turn consists of two other protocols: the Internet Security Association and Key Management Protocol (ISAKMP) and the OAKLEY protocol. ISAKMP defines the procedures for peer authentication, the SA handshake process, and algorithms and key sizes. The OAKLEY protocol performs the actual key negotiation by using yet another protocol, the Diffie-Hellman protocol. Diffie-Hellman will be covered in more detail in the Cryptography chapter. When the symmetric keys and the algorithms are securely negotiated, the SA handshake process will take place as described earlier. IKE uses UDP port 500.
So IPSec is a complex but also very secure protocol. It provides authentication of data origin, data integrity, and confidentiality. By using a Public Key Infrastructure (PKI) with certification authorities and digital certificates, or Kerberos authentication, even user authentication is possible. However, the underlying protocols and algorithms it employs are subject to vulnerabilities. For example, certain implementations of IKE can be vulnerable to brute force attacks.
SSH (Secure SHell)
Secure Shell (SSH) was developed to provide a more secure alternative to remote connectivity protocols such as Telnet, rlogin, rsh, and FTP. The latter do not offer encryption and strong authentication methods, while they are often us ed to transmit sensitive data, i.e. remotely administering Linux servers. By using SSH instead, a secure tunnel can be established between a client and a server, through which all traffic including authentication information can be transmitt ed in an encrypt ed form. In 1997, SSH 2 was developed and should be used instead of version 1 whenever available. SSH 2 includes support for periodic replacement of session keys, public key certificates, DSA and Diffie-Hellman for exchanging session keys, and strong message authentication (SHA-1) to provide integrity checking. Use of SSH-1 should be avoid ed when SSH-2 is available.
When an SSH client initiates a connection, the server replies with its public key to identify itself. If the user decides to trust the key, the client generates a session key, which it sends to the server after encrypting it with the server’s public key. This ensures that only the server can decrypt the session key with its private key. Optionally, the client can send its own public key to authenticate itself to the server. When the session key is exchanged, it is used in conjunction with a symmetric algorithm, such as DES, 3DES, or Blowfish, to encrypt the data. Any type of TCP or UDP traffic can be transmitted over the SSH port (TCP port 22) once the secure session has been established.
The IEEE 802.1x protocol provides authenticat ed access to wir ed Ethernet networks and wireless 802.11 networks. It allows for port-based access control at the Data Link layer (layer 2) for clients connected to switches and wireless access points. When an 802.1x client connects to a physical port on a switch, or associates with a wireless access point, it needs to authenticate itself before it can use other protocols and access network services. The following diagram depicts the three components of a typical 802.1x setup and the authentication process in detail. The supplicant in the diagram is the client requesting access to the network. The authenticator is the switch or WAP to which the supplicant connects, and is responsible for exchanging authentication information between the supplicant and the authentication server. The authentication server is usually a RADIUS server.
You do not need to memorize the entire authentication process for the Security+ exam, but it is important to understand how 802.1x works. As you can see in the diagram above, the switch acts as the authenticator, as a proxy, for the client as it forwards the authentication requests and responses to the authentication server on behalf of the client. 802.1x is also known as EAPOL (EAP over LANs) as it employs the Extensible Authentication Protocol (EAP) for the authentication process, which was originally designed for the dial-up and remote access connections. Until the authentication process has successfully completed and the port enters an authorized state, only EAPOL traffic will be allowed through the port to which the client is connected. Once authenticated, the port will remain in an authorized state and allow traffic to pass through it until the client sends an EAPOL-Logoff message.
In large networks with multiple switches and access points, all authentication requests can be sent to a single RADIUS server providing centralized user administration and accounting. The RADIUS server can be used in conjunction with Windows Active Directory, and other major network operating systems. EAP is a flexible authentication ‘framework’ allowing for different authentication protocols and methods such as smartcards and certificates in addition to username and password credentials.
In wireless networks, 802.1x is particularly useful for providing dynamic key management for WEP keys. Although WEP itself does not offer strong security, using 802.1x to issue unique dynamic keys and to change them frequently during a session can dramatically increase security.