Chapter 13 - Remote Network Access.pdf

Chapter 13 Remote Network Access THE FOLLOWING COMPTIA NETWORK+ EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Domain 3.0 Network Operations 3.5 Compare and contrast network access and management methods. Site-to-site VPN Client-to-site VPN Clientless Split tunnel v...

Chapter 13 Remote Network Access THE FOLLOWING COMPTIA NETWORK+ EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER: Domain 3.0 Network Operations 3.5 Compare and contrast network access and management methods. Site-to-site VPN Client-to-site VPN Clientless Split tunnel vs. full tunnel Connection methods SSH Graphical user interface (GUI) API Console Jump box/host In-band vs. out-of-band management Think of remote access as a telecommuting tool because companies use it to allow remote employees to connect to the internal network and access resources in the office. Remote access is great for users who work from home or travel frequently, but clearly, to a stalking hacker, using an unsecured remote access connection is like stealing candy from a baby. Using remote access requires a server configured to accept incoming calls and also requires remote access software to be installed on the client. Microsoft Windows operating systems, since Windows 95, have had remote access client software built in, and there are many third-party remote access clients available as well. Several different methods exist to create remote access connections. In this chapter, we'll look at remote access and the VPN types that make it secure. To find Todd Lammle CompTIA videos and practice questions, please see www.lammle.com. Site-to-Site VPN Site-to-site VPNs, or intranet VPNs, allow a company to connect its remote sites to the corporate backbone securely over an insecure public medium like the Internet instead of requiring more expensive wide area network (WAN) connections like Frame Relay. This is the best solution for connecting a remote office to a main company office because all traffic between the offices will be encrypted with no effort on the part of the users. In this scenario, all office traffic will go through the VPN tunnel. Figure 13.1 shows a site-to-site VPN, along with a remote access called a client-to-site VPN covered in the next section. This solution requires a remote access client on the user device. FIGURE 13.1 Site-to-site and client-to-site VPN Client-to-Site VPN Remote access VPNs or client-to-site VPNs (shown in Figure 13.1) allow remote users like telecommuters to securely access the corporate network wherever and whenever they need to. It is typical that users can connect to the Internet but not to the office via their VPN client because they don't have the correct VPN address and password. This is the most common problem and one you should always check first. In this scenario, only the user and office traffic will go through the VPN tunnel. This solution requires a remote access client on the user's device. Clientless VPN A clientless VPN enables end users to securely access resources on the corporate network from anywhere using an SSL/TLS-enabled web browser. They need no remote access client to do this, only a browser that can perform SSL or the more secure TLS. Figure 13.2 shows a clientless VPN. Split Tunnel vs. Full Tunnel When a client-to-site VPN is created, it is possible to do so in two ways, split tunnel and full tunnel. The difference is whether the user uses the VPN for connecting to the Internet as well as for connecting to the office. FIGURE 13.2 Clientless VPN Split tunneling works by using two connections at the same time: the secure VPN connection and an open connection to the Internet. So in split tunneling, only traffic to the office goes through the VPN. Internet traffic does not. The security issue with this is that while the user is connected to the VPN, they are also connected to the most untrusted network, the Internet. Figure 13.3 shows the split and full tunnels.  FIGURE 13.3 Split and full tunnels With a full tunnel, all traffic goes through the VPN, which means the user is accessing the Internet through the connection of the office, and so all traffic will be examined by the office security. Remote Desktop Connection There are times when you need to make a remote connection to a machine to perform troubleshooting but you are miles away. Connectivity software is designed to allow you to make a connection to a machine, see the desktop, and perform any action you could perform if you were sitting in front of it. Microsoft has made what it calls Remote Desktop software available for free with Windows products since Windows NT. When this software is installed (installed by default in later versions) on both source and destination computers, a remote desktop connection can be made. Microsoft allows one remote user connection or a local connection on desktop operating systems via Remote Desktop Protocol (RDP), but not both. On server operating systems, Microsoft allows two administrative connections that can be a combination of local or remote access, but not to exceed two connections. RDP can also be used to deliver applications to the end users via Microsoft RemoteApp on terminal services. When RemoteApp is used, the server still requires a terminal services license. However, just the application is delivered to the user host rather than the entire desktop. Commercial tools are also available that (of course) claim to have more functionality, and they probably do have a few extra bells and whistles. These include LogMeIn.com, GoToMyPC, and others. The advantages of these connectivity tools are obvious. With these tools, you can do anything you need to on the machine as long as you can connect. They also allow you to see what a user is actually doing when they encounter a problem rather than having to rely on what they tell you they are doing. You can even show a user what they are doing wrong. Most of these tools allow for chat sessions and for either end of the connection to take control of the machine. You can also transfer files to them if required (maybe a dynamic-link library got deleted, for example). Remote Desktop Protocol Remote Desktop Protocol is a proprietary protocol developed by Microsoft. It allows you to connect to another computer and run programs. RDP operates somewhat like Telnet, except instead of getting a command-line prompt as you do with Telnet, you get the actual graphical user interface (GUI) of the remote computer. Clients exist for most versions of Windows, and macOS now comes with a preinstalled RDP client. Microsoft currently calls its official RDP server software Remote Desktop Services; it was called Terminal Services for awhile. Microsoft's official client software is currently referred to as Remote Desktop Connection (RDC), which was called Terminal Services Client in the past. RDP is an excellent tool for remote clients, allowing them to connect to their work computer from home, for example, and get their email or perform work on other applications without running or installing any of the software on their home computer. RDP allows users to connect to a computer running Microsoft's Remote Desktop Services, but a remote computer must have the right kind of client software installed for this to happen. Most Windows-based operating systems include an RDP client, and so do most other major operating systems, like Linux and macOS. Microsoft began calling all terminal services products Remote Desktop with Windows Server 2008 R2. RDP uses the TCP protocol and port 3389. After establishing a connection, the user sees a terminal window that's basically a preconfigured window that looks like a Windows desktop or another operating system's desktop. From there, the user on the client computer can access applications and files available to them by using the remote desktop. When logged in using RDP, clients are able to access local files and printers from the remote desktop just as if they were logged into the network. EXERCISE 13.1 Experimenting with RDP This exercise is best if you have two stand-alone Windows computers on the same network. In this exercise, you will experiment and explore the setting for Microsoft Remote Desktop Protocol: 1. Select Start Settings System Remote Desktop to open the Windows Settings for Remote Desktop. 2. Flip the Enable Remote Desktop switch to on. 3. Click Confirm on the Enable Remote Desktop? dialog box. 4. Click Advanced Settings to investigate the various settings for Remote Desktop. If you have a second computer, continue with the following steps. 5. On the same computer, find the IP address by opening a command prompt and typing ipconfig. 6. On a second computer, click the Start menu, begin typing the word Remote, and select the Remote Desktop Connection result. 7. Click Show Options on the Remote Desktop App. 8. Explore the tabs and various options. 9. Click the General tab and enter the IP address from step 5. 10. Click Connect on the Remote Desktop App. RDP Gateway The Remote Desktop Protocol Gateway is a Microsoft server role that allows centralized access to remote desktops, such as remote desktop workstations or remote desktop servers. The gateway usually sits between the users and the remote desktops and controls the access to the remote desktops. Although the term Remote Desktop Gateway is a Microsoft Server role, every vendor for Remote Desktop Protocol Services has a similar server or virtual appliance. The Remote Desktop Gateway is mainly responsible for brokering clients to their respective remote desktops. The Remote Desktop Gateway is typically installed on the edge of the network, where it will border the external network it serves, such as the Internet. Because the gateway is installed on the edge of the network, it is also responsible for the security or the remote desktop sessions and users. The gateway provides TLS encryption via certificates, authentication for clients via Active Directory, and the authorization to the internal resources. The Remote Desktop Gateway operates on port 443 and protocol TCP. During the setup of the Remote Desktop Gateway, two policies must be configured for controlling authorization. The Connection Authorization Policy (CAP) specifies which group of users can access the Remote Desktop Gateway. The Resource Authorization Policy (RAP) then specifies which remote desktop or servers are allowed for each group of users. Between the CAP and RAP authentication policies, the Remote Desktop Gateway can be configured with granular security for both users and the remote hosts. It is more secure than allowing RDP to be published directly to the public over the Internet in the following ways: No VPN needed. Using the SSL channel, the RDP Gateway can tunnel directly to the remote server to increase the security of RDS. No pass through a third-party website or service. Native Windows Server service. Can be combined with Network Access Protection (NAP). Can be used along with Microsoft Internet Security and Acceleration (ISA), the Microsoft implementation of RADIUS. Virtual Network Computing Virtual Network Computing (VNC) is a remote control tool for sharing desktops. The VNC client normally operates on TCP port 5900. VNC is similar to Microsoft RDP, with the exception that VNC is an open-source protocol and allows only one console session on a Microsoft operating system. It supports encryption via plug-ins but is not encrypted by default. VNC operates in a client and server model. The server install for the host enables remote control of the host, and the client install allows for means to connect to the VNC server. It is normally configured with a simple shared password, but it can also be configured with Windows groups. Several clients can be used such as RealVNC, TightVNC, and many others, but all of the clients perform in a similar way. VNC includes the following components: VNC server: Software that runs on the machine sharing its screen VNC client (or viewer): Software on the machine that is remotely receiving the shared screen VNC protocol: The protocol One big difference between VNC and RDP is that VNC sends raw pixel data (which does make it work on any desktop type), while RDP uses graphic primitives or higher-level commands for the screen transfer process. Virtual Desktop Using operating system images for desktop computers is not a new concept. Nor is delivering these desktop images to users from a virtual environment when they start their computer. This allows for the user desktop to require less computing power, especially if the applications are also delivered virtually and those applications are running in a virtual machine (VM) in the cloud rather than in the local desktop eating up local resources. Another benefit of using virtual desktops is the ability to maintain a consistent user environment (same desktop, applications, etc.), which can enhance user support. Connection Methods This section will cover various connection methods for accessing hosts, servers, and network devices. We already covered RDP in this chapter, so let's talk about the following: Secure Shell (SSH) Graphical user interface (GUI) Application programming interface (API) Console Secure Shell Secure Shell is a network protocol that is designed as a secure alternative to command- based utilities such as Telnet that transmit requests and responses in clear text. It creates a secure channel between the devices and provides confidentiality and integrity of the data transmission. The SSH protocol uses the TCP protocol and port 22. It uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary. This public key is placed on any computer that must allow access to the owner of a matching private key (the owner keeps the private key in secret). The private key is never transferred through the network during authentication. Don't use Telnet! Telnet is insecure because it sends all data in crystal-clear text— including your name and password. And I'm pretty sure you know that's a terrible thing these days. If Microsoft doesn't even enable it on its latest OSs, then you know it really must be insecure. Figure 13.4 shows how an encrypted session might look between a host and a network device. FIGURE 13.4 Clientless VPN Some configuration is usually necessary if you want things to work as they really should, and yes, sometimes it's a little painful to get everything running smoothly, but it's all worth it in the long run. Personally, I disable Telnet on all my routers and use SSH exclusively. No lie—I never use Telnet anymore if I can help it. Even so, you should still understand Telnet and get some practice with it in case you do ever need it. Graphical User Interface As mentioned earlier, Remote Desktop Services is a great GUI to connect to remote devices, get a GUI window, and then use it to administer the device, server, and/or network devices on the connected zone. Very useful. You'll learn about a jump host in the next section, which can be used similarly. Application Programming Interface An application programming interface allows you to quickly access an application resource without mapping out the application and manually reverse engineering your functionality. For example, if you wanted to create an application that suggests restaurants near a user, you would need access to map information to know what restaurants are nearby. To get map information on your own, you would have to either get your own map data or develop your own way of accessing Google Maps through your own interface. Neither one of these is a practical option. Fortunately, Google offers many APIs that, like you, consume their map information in your application. One of the most common ways of accessing APIs is through Representational State Transfer (REST). REST is a resource-based API, which means that URIs should be: Things, not actions Nouns, not verbs If we break the words in Representational State Transfer apart, we have the following: Representational A resource state is transferred between a client and server. State Transfer Each request has all the information it needs to complete the operation. Lastly, REST has six constraints it needs to follow to be considered a RESTful API. Client-server: Connections are always initiated by a client requesting something from a server. Stateless: The server doesn't store any information from previous requests. Cacheable: The server response includes a version number so the client can decide if it can use the cached information or if it needs a new request. Uniform interface: This defines the interface between the client and the server. This is divided into four subsections. Resource identification: Each resource must have its own unique URI. Resource representation: This is how the resource will return data to the client; this is usually JSON or XML. Self-descriptive messages: Each message sent must have enough information in it to determine how to process the message. Hypermedia as the engine of application state (HATEOAS): This is a bit of a mouthful but basically means you should be able to easily discover other functionalities of the API. For example, suppose you are looking at a Cisco router API to view an interface. In that case, you should be able to view other items without too much documentation. Layered system: You can add layers between the API and the server data, such as a firewall or a load balancer, without impacting operations. Code on demand: This optional constraint allows REST to send executable code responses back to the client. Console/Rolled Serial Cable Although rolled cable isn't used to connect any Ethernet connections together, you can use a rolled Ethernet cable to connect a host EIA-TIA 232 interface to a router console serial communication (COM) port. If you have a Cisco router or switch, you would use this cable to connect your PC, your Mac, or a device like an iPad to the Cisco hardware. Eight wires are used in this cable to connect serial devices, although not all eight are used to send information, just as in Ethernet networking. Figure 13.5 shows the eight wires used in a rolled cable. FIGURE 13.5 Rolled Ethernet cable These are probably the easiest cables to make because you just cut the end off on one side of a straight-through cable, turn it over, and put it back on—with a new connector, of course! Once you have the correct cable connected from your PC to the Cisco router or switch console port, you can start your emulation program such as PuTTY or SecureCRT to create a console connection and configure the device. Set the configuration as shown in Figure 13.6. Notice that Baud Rate is set to 9600, Data Bits to 8, Parity to None, and no Flow Control options are set. At this point, you can click Connect and press the Enter key, and you should be connected to your Cisco device console port. Figure 13.7 shows a nice Cisco switch with two console ports. Notice there are two console connections on this new switch—a typical original RJ45 connection and the newer mini type-B USB console. FIGURE 13.6 Configuring your console emulation program  FIGURE 13.7 A Cisco 2960 console connections Remember that the new USB port supersedes the RJ45 port if you happen to plug into both at the same time, and the USB port can have speeds up to 115,200 Kbps, which is awesome if you have to use Xmodem to update an IOS. I've even seen some cables that work on iPhones and iPads, allowing them to connect to these mini-USB ports! Jump Box/Host Referred to as a jump server, jump host, or jump box, this can be a very useful device. A jump box is defined as a system on a private network that will allow you to remotely access and manage devices in a separate security zone. This host is a very hardened device that connects two or more security zones, allowing authenticated and controlled access between chosen zones. Created in the early 1990s to provide secure access to remote networks and multiple security zones, this was initially used with proxy services, which were all the rage by the mid-1990s, and then provided a connection from a local desktop. However, once SSH became popular and replaced Telnet, SSH became the standard access method instead of proxies for the jump box. Alternatively, I am using a jump box in my data center. I have set it up so I can RDP into the GUI interface and get to all my network devices in the DC I use daily. Similarly, and created around this same time, a bastion host was created. Named bastion because it means or is defined as “Military Fortification” and considered a critical strong point of network security, it was typically designed and configured to stop multiple attacks by only running the needed application, and all other ports are disabled. Another reason to use a bastion is the network interfaces were designed to look for and stop high-bandwidth attacks. Pretty amazing. Jumping back to the jump box (see what I did there?), it's vital that you set up a VPN termination point in the location where the host is located. In my DC, I use a Cisco ASA —it's old but sturdy—and can handle all my terminations with an easy-to-use CLI. Where Should You Implement a Jump Box/Host? Jump servers are often placed between a secure zone and a screened subnet (also known as DMZ) to provide easy management of devices in the screened subnet once a management session has been set up and configured. Figure 13.8 shows where a typical jump host could be placed in a network. Notice my firewall termination point for my VPN. This allows for an administrator to log into the jump server to gain access to the screened subnet, servers, and other assets, and all access and configuration can be logged for audit. FIGURE 13.8 Where a jump box is implemented In-Band vs. Out-of-Band Management Out-of-band management is any method of managing a server or network device that does not use or go through the network. You'd use a console cable to attach directly to the device to do this. However, many newer network devices have separate Ethernet ports that are configured with a different subnet than the management IP of the local zone and is considered out- of-band because it is not connecting through the production network. In-band refers to managing a network, server, or network device through the network using tools like RDP or SSH, for example. Summary