Lesson 2: Providing Secure Remote Access

From the network layer up, a remote connection is no different than a direct local area network (LAN) connection, but the data-link and physical layers can take several different forms. To understand how to provide secure access to your remote access users, you must understand the standards and protocols associated with remote access and the security configurations that can be used.

After this lesson, you will be able to

Understand the authentication protocols that can be used to secure a remote access connection
Understand how RADIUS can be used to provide centralized remote access authentication
Understand how TACACS can be used to provide centralized remote access authentication

Estimated lesson time: 25 minutes

Remote Connection Requirements

For a remote computer to communicate with a server, both computers must have common protocols at the physical and data-link layers. They must also be configured to provide secure communications, and the server should be configured to require the remote user to authenticate. Figure 5-2 displays required elements for a remote connection and gives a brief explanation of each.

figure 5-2 remote connection requirements

Figure 5-2. Remote connection requirements

When remote users are authenticated and gain access to networked resources, you should limit the access they have to only those resources required to complete necessary tasks. For instance, if the remote access users at your company require only the ability to access e-mail, then only provide them access to e-mail. The protocols used at the different layers include the following:

Common data-link layer protocols.
The two computers to be connected must share common protocols at the data-link layer and above. This means that you must configure both computers to use a data-link layer protocol suitable for point-to-point connections, such as PPP or SLIP. There must also be network and transport layer protocols in common, such as Transmission Control Protocol/Internet Protocol (TCP/IP), Internetwork Packet Exchange (IPX), Network Basic Input/Output System (NetBIOS), or NetBIOS Enhanced User Interface (NetBEUI).
TCP/IP configuration.
If your remote computer will be using TCP/IP to communicate with the host network, the computer must be assigned an IP address and other configuration parameters appropriate for that network. You can configure the TCP/IP settings if someone familiar with the host network supplies them to you, but most remote networking solutions enable the network server to assign configuration parameters automatically using Dynamic Host Configuration Protocol (DHCP) or some other mechanism.
Host and remote software.
Each of the computers to be connected must be running an application appropriate to its role. The remote (or client) computer needs a client program that can use the physical layer medium to establish a connection (by instructing the modem to dial a number, for example). The host (or server) computer must have a program that can respond to a connection request from the remote computer and provide access to the network.
Security.
The host computer and the other systems on the network to which it is attached must have security mechanisms in place that control access to network resources to ensure that only authorized users are permitted access and to restrict the access of those authorized users to only the resources they need.

Using Authentication Mechanisms

The PPP protocol used with remote access is combined with one of several authentication mechanisms that provide varying degrees of security and support differing levels of encryption. Each remote access server can be configured to authenticate remote users, or centralized authentication and access control can be used. The following are examples of remote access authentication methods:

Password Authentication Protocol (PAP).
PAP requires a password, but the password is sent in cleartext, so PAP is not a very secure authentication mechanism. All 32-bit Windows operating systems include remote access client support for PAP.
Shiva Password Authentication Protocol (SPAP).
SPAP incorporates a reversible encryption mechanism. SPAP is more secure than PAP, but does not provide protection against remote server impersonation. All 32-bit Windows operating systems include remote access client support for SPAP.
Challenge Handshake Authentication Protocol (CHAP).

Defined in Request for Comments (RFC) 1994, CHAP uses the Message Digest 5 (MD5) hashing algorithm to hash the password. (RFC articles can be found at http://www.icann.rfceditor.org.) The hash is then sent from client to server. Only the remote access server can send the password challenge. Because the password is never sent from the client to the server, this is more secure than PAP or SPAP. All 32-bit Windows operating systems include remote access client support for CHAP.
Microsoft Challenge Handshake Authentication Protocol (MS-CHAP).
Microsoft's implementation of the CHAP protocol provides greater security than CHAP, in addition to Microsoft networking domain login support capabilities. MS-CHAP uses the Message Digest 4 (MD4) hash made up of the challenge string, session ID, and the MD-4 hashed password. All 32-bit Windows operating systems include remote access client support for MS-CHAP.
Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2).
MS-CHAPv2 introduces larger initial encryption key size and support for bidirectional challenge. This allows the client to send a challenge to the remote access server. MS-CHAPv2 also uses MD4 for hashing of the password. All 32-bit Windows operating systems include remote access client support for MS-CHAPv2.

Centralized Authentication

Authentication can be provided by each of the remote access servers used, or it can be provided through centralized authentication and access control. Figure 5-3 shows a centralized authentication server validating the authentication requests that the remote access servers are receiving from the remote access clients. Enabling centralized authentication is done by configuring a server to support Remote Authentication Dial-In User Service (RADIUS), or Terminal Access Controller

Access Control Service (TACACS) or TACACS+, and then configuring the remote access server to use the RADIUS or TACACS server to authenticate the remote access clients.

figure 5-3 centralized remote access authentication

Figure 5-3. Centralized remote access authentication

In Chapter 4, you were introduced to the RADIUS and TACACS authentication protocols as they relate to your network infrastructure. In this section you learn the part they play in centralized authentication.

RADIUS

RADIUS is used for providing authentication, authorization, and accounting services for remote access services and separates the remote access server functions from the user authentication server functions. The communication between the computer that provides remote access support and the computer that provides user authentication is established using RADIUS. The separation of remote access and user authentication allows the following:

The RADIUS client and server to support different operating systems and hardware architectures.
The RADIUS client and server to be geographically separated.
User accounts to be secure by ensuring that the accounts are located on servers within the private network and not directly exposed to the Internet.
Encryption of authentication traffic between the RADIUS client and the RADIUS server using Internet Protocol Security (IPSec) or VPN tunnels.
Outsourcing of dial-up remote access to third-party organizations.

The remote access client connectivity feature provided by the RADIUS client determines how remote users access the private network. The remote access client connectivity provided by the RADIUS client allows the remote access users to do the following:

Use a variety of authentication protocols, such as CHAP, MS-CHAP, or clear text to get authenticated.
Encrypt data using a variety of encryption algorithms, such as Microsoft Point-to-Point Encryption (MPPE) or Data Encryption Standard (DES).
Connect using a variety of protocols, such as TCP/IP or Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX).
Connect using a variety of technologies, such as dial-up modems, DSL, or ISDN.

Remote user authentication provided by the RADIUS server determines the user accounts that are authenticated, and the accounting provided by the RADIUS server creates a historical record of RADIUS transactions that occur between the client and RADIUS server. Remote user accounting records the following information:

The length of time the remote user is connected
Remote user authentication success or failure
Situations when the RADIUS server is unable to authenticate a RADIUS client

The purpose of having RADIUS clients and servers is to centralize and secure the authentication of remote users. Instead of allowing all remote clients to send a RADIUS request to a RADIUS server, only a small number of RADIUS clients are authorized. However, even this reduced number of RADIUS clients allows the possibility of someone attempting to impersonate a RADIUS client when communicating with a RADIUS server.

To thwart such an attempt, the administrator sets a password, called a shared secret, during the configuration of RADIUS. Both the RADIUS client and server know the shared secret, but it is never sent over the network. Instead, the service uses a hashing system to verify the shared secret. The location of each RADIUS client that will be sending authentication packets is specified to the RADIUS server, and only these specified RADIUS clients can forward authentication packets to a RADIUS server.

The shared secret is not used between just the RADIUS client and server. The shared secret is also used during the encryption process for a remote access client's password. This means that a shared secret needs to always be included in a RADIUS solution, and it needs to be a password that is difficult to guess. Like any password, a shared secret is case-sensitive and must match exactly on RADIUS clients and servers.

RADIUS Authentication and Accounting

Now that you understand what RADIUS does, refer to Figure 5-4 while reviewing the RADIUS authentication process that follows.

Access servers, such as dial-up network access servers, VPN servers, and wireless access points, receive connection requests from access clients.
The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol creates an Access-Request message and sends it to the RADIUS server.
- The RADIUS server evaluates the Access-Request message.
- If required (as is the case when Extensible Authentication Protocol [EAP] is used), the RADIUS server sends an Access-Challenge message to the access server. The access server or access client processes the challenge and sends a new Access-Request to the RADIUS server.
- The user credentials and the authorization of the connection attempt are verified.
If the connection attempt is both authenticated and authorized, the RADIUS server sends an Access-Accept message to the access server.
- If the connection attempt is either not authenticated or not authorized, the RADIUS server sends an Access-Reject message to the access server.
On receipt of the Access-Accept message, the access server completes the connection process with the access client and sends an Accounting-Request message to the RADIUS server.
After the Accounting-Request message is processed, the RADIUS server sends an Accounting-Response message to the access server.
The client connection request is completed.

figure 5-4 radius authentication process

Figure 5-4. RADIUS authentication process

TACACS and TACACS+

TACACS provides a way to centrally validate users attempting to gain access to a router or access server. TACACS+ was designed by Cisco Systems, Inc., and it provides a standard method for managing dissimilar network access servers (NASs) from a single set of management services. An NAS provides connections to a single user, to a network or subnetwork, and to interconnected networks. TACACS+ has three major components:

The protocol support within the access servers and routers
The protocol specification
The centralized security database

Similar to an internal security database, TACACS+ supports the following three required features of a good security system:

Authentication.
The TACACS+ protocol forwards many types of user name and password information. This information is encrypted over the network with MD5. TACACS+ can forward the password types for Apple Remote Access (ARA), SLIP, PAP, CHAP, and standard Telnet. This allows clients to use the same user name and password for different protocols. TACACS+ is extensible to support new password types such as Kerberos CHAP (KCHAP).

TACACS+ authentication supports multiple challenge and response demands from the TACACS+ server. This allows token card vendors to provide advanced features such as sending back a second token-generated number after the first one is manipulated by a security server.
Authorization.
TACACS+ provides a mechanism to tell an access server which access list a user connected to port 1 uses. The TACACS+ server and location of the user name and password information identify the access list through which the user is filtered. The access list resides on the access server. The TACACS server responds to a user name with an Accept message and an access list number that causes that list to be applied.
Accounting.
TACACS+ provides accounting information to a database through TCP to ensure a more secure and complete accounting log. The accounting portion of the TACACS+ protocol contains the network address of the user, the user name, the service attempted, protocol used, time and date, and the packet-filter module originating the log. The billing information includes connect time, user ID, location connected from, start time, and stop time. It identifies the protocol that the user is using and might contain commands being run if the users are connected through Telnet. The auditing information includes which commands and arguments were used and the connection the command came from. The protocol provides enough information so that a server can produce intruder detection routines, reporting statistics, number of packets, and number of bytes.

RADIUS and TACACS+ Differences

There are many differences between RADIUS and TACACS+, but some of the key differences are the following:

RADIUS runs over User Datagram Protocol (UDP), whereas TACACS+ runs over TCP. As a result, the transport is more reliable and less sensitive to disruption of the lower layers.
RADIUS provides a user profile with authentication that defines all the user-specific parameters, whereas TACACS+ separates authentication and authorization.
TACACS is typically used only for network devices, such as routers and switches, whereas RADIUS is used by computers and network devices.

Virtual Private Networks

Authentication methods provide a mechanism to authenticate a remote user, but do not provide protection for data that is traveling across a public communication medium. A VPN, as shown in Figure 5-5, is a secure connection between a remote computer and a server on a private network that uses the Internet as its network medium. The network is permanently connected to the Internet and has a server that is configured to receive incoming connections through the Internet. The remote user connects to the Internet by using a modem to dial in to an ISP located nearby. Many ISPs offer national and even international service, so users can connect to the Internet with a local telephone call.

The remote computer and the network server then establish a secured connection that protects the data exchanged between them as it travels over the Internet. This technique is called tunneling, because the connection runs across the Internet inside a secure conduit, protecting the data in the way that a tunnel under a river protects cars from the water above it.

figure 5-5 example of a virtual private network

Figure 5-5. Example of a virtual private network

In general, security is not a single product or technology, but an integration of several technologies combined with management policy that provides protection balanced with acceptable risks. Security services should include confidentiality, integrity protection, authentication, authorization, and replay protection. Some protocols that are used in association with VPNs include the following:

Point-to-Point Tunneling Protocol (PPTP).
Created by the PPTP Industry Forum (US Robotics [now 3Com], 3Com/Primary Access, Ascend, Microsoft, and ECI Telematics).
Layer 2 Tunneling Protocol (L2TP).
A combination of PPTP and L2F (designed by Cisco Systems), which evolved through the Internet Engineering Task Force (IETF) standards process.
Internet Protocol Security (IPSec).

An architecture, protocol, and related Internet Key Exchange (IKE) protocol, which are described in RFCs 2401 through 2409.

Point-to-Point Tunneling Protocol

One protocol that makes VPN tunneling possible is PPTP. PPTP works with PPP to establish a connection between the client computer and a server on the target network, both of which are connected to the Internet. The connection process begins with the client computer dialing up and connecting to a local ISP, using the standard PPP connection establishment process. When the computer is connected to the Internet, it establishes a control connection to the server using TCP. This control connection is the PPTP tunnel through which the computers transmit and receive all subsequent data. The following are some characteristics of PPTP:

It is a Layer 2 protocol that encapsulates PPP frames in IP datagrams for transmission over an unsecured public IP network, such as the Internet.
It accomplishes authentication through the same methods as PPP, including PAP, CHAP, and MS-CHAP.
It requires an IP-based network and header compression is not supported. PPTP does not support IPSec, and encryption is provided using standard PPP methods.

When the tunnel is in place, the computers send their data through it by encapsulating the PPP data that they would normally transmit over a dial-up connection within IP datagrams. The computer then sends the datagrams through the tunnel to the other computer. Although it violates the rules of the Open Systems Interconnection (OSI) model, the data-link layer frame is carried within a network layer datagram.

The PPP frames are encapsulated by IP, and they can also contain other IP datagrams, which contain the actual user data that one computer is sending to the other. Thus, the messages transmitted through the TCP connection that forms the tunnel are IP datagrams that contain PPP frames, and the PPP frames can contain messages generated by any network layer protocol. Therefore the data can be:

Another IP datagram
An IPX message
A NetBEUI message

Because the tunnel is encrypted and secured using an authentication protocol, the data is protected from interception. After the IP datagrams pass through the tunnel to the other computer, the PPP frames are extracted and processed by the receiver in the normal manner. Most Network Address Translation (NAT) implementations include protocol editors for the Generic Routing Encapsulation (GRE) protocol, which is used by PPTP for control packets and TCP 1723 traffic, which uses the PPTP tunnel. PPTP also supports many protocols and multicast environments, and it combines standard user password authentication with strong encryption, without the complexity and expense of a Public Key Infrastructure (PKI).

Layer 2 Tunneling Protocol

L2TP is a mature, widely implemented IETF standards track protocol. L2TP encapsulates PPP frames to be sent over IP, X.25, Frame Relay, or Asynchronous Transfer Mode (ATM) networks. When configured to use IP as its transport, L2TP can be used as a VPN tunneling protocol over the Internet. L2TP over IP uses UDP port 1701 and includes a series of L2TP control messages for tunnel maintenance.

L2TP also uses UDP to send L2TP-encapsulated PPP frames as tunneled data. These encapsulated PPP frames can be encrypted or compressed. When L2TP tunnels appear as IP packets, they take advantage of standard IPSec security using IPSec transport mode for strong integrity, replay, authenticity, and privacy protection. L2TP was specifically designed for client connections to network access servers and gateway-to-gateway connections.

PPP also provides a wide range of user authentication options, including CHAP, MS-CHAP, MS-CHAPv2, and EAP, which supports token card and smart card authentication mechanisms. L2TP/IPSec therefore provides well-defined, interoperable tunneling, with the strong and interoperable security of IPSec.

When possible, use multifactor authentication. The three factors are Type 1, which is something you know, such as a password; Type 2, which is something you have, such as a smart card; and Type 3, which is something you are, such as a fingerprint. For instance, you could require remote users to have a smart card for authenticating with the remote server. When authenticating, the user could be required to provide a personal identification number (PIN) as part of the authentication process. For something you are, a retinal scanner or thumbprint reader could be used. The most common and most secure method is combining something you have with something you know.

By placing L2TP as a payload within an IPSec packet, communications benefit from the standards-based encryption and authenticity of IPSec, while also having a highly interoperable way to accomplish user authentication, tunnel address assignment, multiprotocol support, and multicast support using PPP. This combination is commonly referred to as L2TP/IPSec.

Due to incompatibilities between the IKE protocol and NAT, it is not possible to use L2TP/IPSec or IPSec tunnel mode through an NAT while taking advantage of automated key exchange with most current NAT implementations. NAT traversal (NAT-T) technologies should be available in early 2003 that will allow IPSec to work through NAT connections by encapsulating the IPSec packets in UDP packets.

Internet Protocol Security

With IPSec, you can provide privacy, integrity, and authenticity for network traffic in the following situations:

End-to-end security for IP unicast traffic, from client to server, server to server, and client to client using IPSec transport mode.
Remote access VPN client and gateway functions using L2TP secured by IPSec transport mode.
Site-to-site VPN connections, across outsourced private wide area network (WAN) or Internet-based connections using L2TP/IPSec or IPSec tunnel mode.

An automatic security negotiation and key management service is also provided using the IETF-defined IKE protocol. Implementing IKE provides three authentication methods to establish trust between computers:

IKE uses only the authentication properties of Kerberos v5 authentication. (For more information, go to http://www.ietf.org/proceedings/99mar, click the link to Section 2.6.2, and then click the Internet draft titled "A GSS-API Authentication Mode for IKE.")
Public/private key signatures using certificates are compatible with several certificate systems, including Microsoft, Entrust, VeriSign, and Netscape.
Passwords, termed preshared authentication keys, are used strictly for establishing trust between computers.

IPSec provides integrity protection, authentication, and (optional) privacy and replay protection services for IP traffic. IPSec packets are of two types:

IP protocol 50 called the Encapsulating Security Payload (ESP) format, which provides confidentiality, authenticity, and integrity.
IP protocol 51 called the Authentication Header (AH) format, which provides integrity and authenticity for packets, but not confidentiality.

IPSec can be used in two modes: transport mode, which secures an existing IP packet from source to destination, and tunnel mode, which puts an existing IP packet inside a new IP packet that is sent to a tunnel endpoint in the IPSec format. Both transport and tunnel mode can be encapsulated in ESP or AH headers.

IPSec transport mode was designed to provide security for IP traffic end to end between two communicating systems (for example, to secure a TCP connection or a UDP datagram). IPSec tunnel mode was designed primarily for network midpoints, routers, or gateways, to secure other IP traffic inside an IPSec tunnel that connects one private IP network to another private IP network over a public or untrusted IP network (for example, the Internet). In both cases, a complex security negotiation is performed between the two computers through the IKE, normally using PKI certificates for mutual authentication.

The IETF RFC IPSec tunnel protocol specifications did not include mechanisms suitable for remote access VPN clients. Omitted features include user authentication options or client IP address configuration. To use IPSec tunnel mode for remote access, some vendors chose to extend the protocol in proprietary ways to solve these issues. Although a few of these extensions are documented as Internet drafts, they lack standards status and are not generally interoperable.

A limitation of IPSec is that it only supports unicast IP datagrams. No support for multicasts or broadcasts is currently provided.

IPSec can have an impact on network performance, dependent on the network configuration. Ensuring that the routers and firewalls have sufficient memory and processor capacity helps minimize performance degradation.

Comparing VPN Solutions

Although L2TP/IPSec is an excellent solution for multivendor interoperability in both client-to-gateway and gateway-to-gateway scenarios, its usage of IPSec does require a PKI to be scalable. Also, because of incompatibilities between IKE and NAT, neither L2TP/IPSec, IPSec pure tunnel mode, nor IPSec transport can pass through typical NATs. Table 5-1 summarizes some of the key technical differences among these three security protocols.

Table 5-1. VPN Solution Comparisons
Capability	PPTP/PPP	L2TP/PPP	L2TP/IPSec	IPSec/Transport	IPSec/Tunnel
User authentication	Yes	Yes	Yes	Yes	Yes
Machine authentication	Yes	Yes	Yes	Yes	Yes
Interoperates with NAT	Yes	Yes	No	No	No
Can carry non-IP packets	Yes	Yes	Yes	No	Yes
Supports encryption	Yes	Yes	Yes	Yes	Yes
Supports PKI	Yes	Yes	Yes	Yes	Yes
Packet authentication	No	No	Yes	Yes	Yes
Supports multicast	Yes	Yes	Yes	No	Yes

Secure Shell Protocol

The Secure Shell (SSH) protocol and software package was originally developed at the Helsinki University of Technology as a secure, low-level transport protocol. SSH allows users to log on to a remote computer over the network, execute commands on it, and move files from one computer to another while providing strong authentication and secure communications over unsecured channels.

SSH is intended as a replacement for Telnet, rlogin, rsh, and rcp on UNIX-based computers. To provide secure file transfer, SSH2 has been introduced as a replacement for FTP: SFTP.

Visit the IETF Web site at http://www.ietf.org for more information on SSH and SSH2.

This technology secures connections over the Internet by encrypting passwords and other data. Once launched, SSH transparently provides strong authentication and secure communication over unsecured networks.

SSH provides host and user authentication, data compression, protection for data confidentiality, strong encryption, cryptographic host authentication, and integrity protection. However, SSH is not designed to protect against flaws inherent in the operating system, such as poorly developed IP stacks and insecure password storage. The SSH protocol consists of three major components:

The transport layer protocol (SSH-TRANS) provides secure authentication, confidentiality, and network integrity. The possibility of SSH-TRANS providing encryption is also available. Transport is typically run over a TCP/IP connection, but it can also be used on top of another reliable data stream.
The user authentication protocol (SSH-USERAUTH) authenticates the client-side user to the server. It runs over the transport layer protocol.
The connection protocol (SSH-CONN) multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol.

SSH uses public key encryption as the main method for user authentication, but rhosts/shosts authentication can be used as well. Through these methods of authentication, SSH provides secure access to a specific account over a network. You can verify that the public key the server sends is the same as the previous one by using strict host key checking. This also prevents users from accessing a host for which they do not have a public key. SSH also provides protections from the following:

Packet spoofing.
An IP packet appears to be yours, but it is actually someone else's.
IP/Host spoofing.
An IP address or host name is yours, and someone else is using it.
Password sniffing.
The network packets that contain your password are read.
Eavesdropping.
The network packets are read and someone sees what you are typing.

SSH provides a UNIX administrator with the ability to run secure sessions through an untrusted network. Because of the way SSH is written, it is designed to be a drop-in replacement for remote connections like the Berkeley services, such as rlogin, rsh, and rcp. In addition to authenticating, SSH provides an encrypted session to protect against spoofed packets and password sniffing. This enables you to use your account over an unsecured channel and still not pass data in the clear.

Exercise: Configuring the Authentication Method for a Dial-Up Connection

In the following exercise, you learn how to configure the authentication method for a dial-up connection on a computer running Microsoft Windows 2000. (This exercise should work similarly on Windows ME, Windows 98, and Windows XP, although the steps may vary slightly.)

From the Start menu, open Control Panel.
Open Network Connections.
1. Open Network and Dial-up Connections
2. Create a new connection by running the Make New Connection Wizard
Complete the Create a Network Connection Wizard to create a dial-up connection using the following information:
1. Dial-up to a private network
2. Select the device you wish to use for this dial-up connection
3. Any phone number
4. Allow only yourself to use the connection
5. Use the default name for the new connection
Open the Properties dialog box for the connection you just created by right-clicking the connection and selecting Properties.
In the Security tab, click Advanced (Custom Settings) and then click Settings.
Click Allow These Protocols, and then select each of the check boxes.
Right-click on the protocols that can be selected and select What's This? from the shortcut menu.
Review the information for each of the protocols and answer the following questions:
1. For PAP, is the password encrypted?
2. For CHAP, is MD4 or MD5 used?
3. Does MS-CHAPv2 offer one-way or mutual authentication?
Click Cancel to close the Advanced Security Settings dialog box without saving any changes.
Click Cancel again to close the Dial-Up Connection Properties dialog box.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson and then try the question again. Answers to the questions can be found in Appendix A, "Questions and Answers."

During port-based access control interaction, an authenticator
1. Enforces authentication before it allows user access to the services
2. Requests access to the services
3. Checks the supplicant's credentials
4. Allows data exchange between two ports
Which protocols support VPN tunneling?
1. PPP
2. PPTP
3. TCP
4. SLIP
A RADIUS server can only provide authentication for one remote access server. (True or False?)
Select all of the following that are advantages of TACACS+:
1. Provides a standard method for managing dissimilar networks
2. Provides distributed user validation for users attempting to gain access to a router or access server
3. Provides centralized validation for users attempting to gain access to a router or access server
4. Runs over UDP for more efficient communications
The L2TP protocol uses which port?
1. 443
2. 80
3. 1701
4. 29
Which do SSH protect against?
1. NFS mounting
2. Packet spoofing
3. Password sniffing
4. Internet attacks

Lesson Summary

Providing remote access to your network introduces security risks that must be mitigated by implementing strong user authentication and authorization methods.

A VPN is a connection between a remote computer and a server on a private network that uses the Internet as its network medium.
PPTP is a tunneling protocol that helps provide a secure, encrypted communications link between a remote client and a remote access server. Other protocols that are associated with VPNs include IPSec, IKE, L2F, and L2TP.
RADIUS provides centralized authentication, authorization, and accounting services for remote access connectivity.
TACACS+ provides a way to centrally validate users attempting to access a router or access server.
SSH provides strong authentication and secure communications over unsecured channels and protects against packet spoofing, IP spoofing, host spoofing, password sniffing, and eavesdropping.