Cisco's Simple Route to a Secure Lab Environment

A lab environment comprises a group of computers that aren't subject to the same management and security standards as the rest of your infrastructure. Perhaps you need a lab environment for computers that aren't managed by corporate IT or for testing software before you deploy it on the corporate network. If you aren't afraid to get your hands dirty with the Cisco IOS command line, you might be able to set up a network for your lab environment without purchasing any additional network equipment. Using existing equipment also lets the lab access the Internet through your existing connection and lets users access the lab from their desktop on the corporate network.

In this article, I describe how to set up a lab network by using VLANs and ACLs—features common on both Cisco hardware and equipment from other vendors. Computers on the lab network will be able to access the Internet, and users will be able to use Remote Desktop Protocol (RDP) to access computers on the lab network. Furthermore, computers on the lab network will be unable to access computers on the corporate network, thereby protecting corporate assets from the unmanaged lab environment.

The Equipment
For the purpose of this article, I used a Cisco Catalyst 2950 switch and a Cisco 800 router. Most Cisco equipment supports VLANs and ACLs. Network equipment from other vendors might also support these features, but configuration commands vary from vendor to vendor. Chances are that your existing network equipment has everything you need to set up a solution similar to the one I describe here.

Cisco IOS Logon and Backup
If someone else configured your network equipment, you might be a bit rusty on how to access it. Most devices have a Web-based UI, but in this article, I use the Cisco IOS command line to access the device's full functionality. You'll need to know either the console or Telnet password, and the Enable password, the Cisco IOS equivalent of the Administrator or root password.

Start by connecting a rolled cable from the port labeled Console on the router or switch to a computer's serial port. Cisco equipment typically comes with a baby blue rolled cable that you can identify by the appropriate RJ-45 and 9-pin serial port connectors at either end. Next, use Microsoft HyperTerminal to connect to the device. You might also simply Telnet to the device's IP address if it's configured for Telnet access. Figure 1 shows the appropriate HyperTerminal settings.

The Cisco IOS command prompt is similar to the DOS command prompt or Microsoft's Netsh. For those who aren't command-line savvy, I'll describe the commands I use in this article in detail, but you can also look at the official documentation for all IOS commands on Cisco's Web site (http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/).

You should always back up the current configuration before making changes to a router or switch. One backup method is to simply copy the configuration to your computer. You'll need Trivial FTP (TFTP) server software. If you don't already have a TFTP server, Solarwinds (http://solarwinds.net/FreeTools.htm) provides one for free.

At the IOS command line, type

enable

to enter privileged mode. Privileged mode removes the IOS security restrictions from your session, letting you change the configuration. Enter the Enable password when the system prompts you to do so. You'll enter all this article's commands in privileged mode. You'll know you're in privileged mode when your IOS prompt ends with a number sign (#).

Next, use IOS's Copy command to back up the current configuration. Like its DOS counterpart, Copy in IOS takes two arguments: source and destination. Instead of filenames, the arguments IOS accepts are startup-config, running-config, and tftp. Startup-config is the configuration the device boots with, running-config is the device's current configuration, and tftp copies to or from a TFTP server.

To back up the current configuration, type

copy running-config tftp

The system will prompt you for the IP address of the machine running the TFTP server and a filename. After the upload is finished, ensure that the config file is now on your local computer by checking the folder you configured for your TFTP server. To restore this configuration to the router or switch, you can use the command

copy tftp running-config

Now that you have a backup and know how to restore it, you're ready to start modifying your configuration.

Logical Network Segregation with VLANs
Examine the network layout that Figure 2 shows. A corporate desktop (CorpBox) and a machine not supported by corporate IT (LabBox) share subnet 192.168.0.0/24 and can communicate freely. The subnet also contains a router that provides access to the Internet and other corporate subnets.

Our goal is to use VLANs to segregate LabBox from CorpBox so that devices running on the lab network can't interact with those running on the corporate network. A VLAN is a logical grouping of Ethernet ports on your switch. All devices connected to ports on the same VLAN can communicate, but the devices can't communicate with devices on other VLANs. Here are the steps we need to take to accomplish our goal.

Log on to the switch and enter the aforementioned commands by following the example that Figure 3 shows. After you exit config-if and config modes, you can use the command

show vlan brief

to check the results. At this point, you should also try to ping CorpBox from LabBox. This attempt will fail because the two machines now operate as if they're on separate switches.

Just as the VLAN configuration separates LabBox from CorpBox, it also separates LabBox from the router. Because the router provides Internet access, LabBox can no longer access the Internet. CorpBox and the router still share VLAN1, so CorpBox has Internet access.

Inter-VLAN Routing
Users will need to access the lab from the production network, so we'll have to assign the lab network a unique subnet and route traffic between the two subnets. First, connect an Ethernet cable to a free port on the router and the switch. I used Ethernet 1 on the router and FastEthernet 0/2 on the switch. On the switch, assign the port you just connected to the router to VLAN2, just as we did for LabBox. (For an alternative method, see the "Trunking" sidebar, page 47.)

Next, log on to the router and assign the IP address 192.168.1.1 to interface Ethernet 1. Using IOS on a router is similar to using IOS on a switch. The Enable, Config T, and Interface commands work the same way. Because a router is a Layer 3 device, you can assign its interfaces IP addresses from config-if mode by using the IP Address command, which you'll find in the IOS documentation's IP Addressing Services section. Interfaces on Cisco routers "administratively down" by default, which essentially means that IOS turns them off until you tell it otherwise. To enable the interface, issue the No Shutdown command. Figure 4 shows the exact commands.

Assign LabBox the IP address 192.168.1.2 and the default gateway 192.168.1.1. Your network should now look something like Figure 5. If the router isn't the only router on your network, you'll need to inform the other routers about the new subnet so that users can access the subnet from anywhere on your network. One common way to do so is to use a routing protocol. Routing protocols let routers automatically share information about the subnet each router can access. Figure 6 shows the commands you should issue to enable the Router Information Protocol (RIP) on your router for the new subnet. If your network uses another routing protocol, such as Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP), or Open Shortest Path First (OSPF), use that protocol instead. If your network doesn't use a routing protocol, you'll have to configure static routes to the 192.168.1.0 subnet on each router.

As you can see in Figure 6, I used the Router Rip command to enter the config-router mode for the RIP routing protocol. Next, I used the Network command to enable RIP routing for the new 192.168.1.0 subnet. Doing so tells the router to advertise the 192.168.1.0 subnet to other routers it communicates with by using RIP. You can find the Router Rip, Network, and similar commands for other routing protocols in the IOS documentation's IP Routing Protocols section.

Note that I didn't have to specify a subnet mask while configuring RIP. RIP uses classful routing, which means that it automatically determines that 192.168.1.0 is a class C subnet and is therefore valid for all IP addresses from 192.168.1.1 to 192.168.1.254. Some networks might use classless routing to make better use of their IP address space. If your network uses a more complicated, classless subnetting scheme, you might want to read up on Classless Interdomain Routing (CIDR) in Cisco's online document "IP Addressing and Subnetting for New Users" (http://www.cisco.com/warp/public/701/3.html).

Both CorpBox and LabBox should now be able to ping each other. LabBox should also be able to ping Internet hosts such as Google.com.

Restricting Everything but RDP
If you're thinking we're right back where we started, you're almost correct. The difference is that we can now use ACLs on the router to limit access to and from the lab network. Cisco ACLs are similar in concept to the ACLs that NTFS uses, but instead of limiting access to files, they limit which packets traverse a router interface.

LabBox is running Microsoft Terminal Services, so the first ACL rules we'll configure will let users from the corporate subnet use Remote Desktop Client to access the lab subnet. Remote Desktop Client and Terminal Services use the RDP protocol to communicate. RDP operates on TCP port 3389.

To allow RDP, we must configure access lists to permit inbound traffic destined for port 3389 on the lab subnet. Cisco IOS supports two types of ACLs to control traffic that uses the IP protocol: standard IP ACLs and extended IP ACLs. Both let you control traffic by using information such as the IP address, but extended ACLs also let you use information from protocols that rely on IP, such as TCP. Because we need to limit traffic by TCP port, we'll use an extended IP ACL. You must use a unique number to identify each ACL you create. The type of ACL determines the numbers from which you can choose. Extended IP ACLs can be numbered 100 to 199 or 2000 to 2699. For my tests, I arbitrarily used extended IP ACL 110, which hadn't yet been assigned to an ACL on my router. The first Access-List command that Figure 7 shows permits TCP traffic from any source IP address to destination IP addresses on the subnet 192.168.1.0/24 if the destination TCP port is 3389.

Notice that the number after the subnet's IP address is like a subnet mask, but inverted. Cisco calls this number a wildcard, and it specifies bits to ignore when comparing the ACL's IP address with each packet's IP address. We want it to ignore the last octet of the IP address, so the last octet of the wildcard is 255—or eight 1s. You can read more about the Access-List command in the IOS documentation's IP Application Services section.

In addition to permitting inbound RDP, we have to permit hosts on the lab subnet to respond to that traffic. The second Access-List configured in Figure 7 permits TCP traffic with a source IP address on the lab subnet to any destination IP address for established connections. This ACL will let hosts on the lab subnet respond to TCP connection requests, but it will deny packets (called SYN packets) that originated on the lab subnet and are seeking to establish a TCP connection.

Cisco IOS processes ACLs on traffic as it enters or leaves a router interface, so before your ACL can do anything, you must tell IOS which interface the ACL should apply to and whether it should apply to traffic entering the router by that interface or traffic leaving the router by that interface. We'll assign the ACLs we configured to interface Ethernet 1 on the router since they were designed to limit traffic to the lab network connected to interface Ethernet 1. Each router interface can have—in Cisco terminology—an outgoing and an inbound ACL. Remember that the direction refers to how a packet travels through the router interface, not how it travels through the network. Therefore, the ACL we assign to the outbound direction of interface Ethernet 1 will apply to packets traveling from some other subnet, such as the corporate subnet or the Internet, into the lab subnet. After an ACL is assigned, the router will implicitly deny any traffic the ACL doesn't permit, so in addition to permitting RDP, we have denied all other traffic. Figure 7 shows how to use the IP Access-Group command from config-if mode to assign ACLs 110 and 120 to the outgoing and inbound directions of interface Ethernet 1. You can read more about the IP Access-Group command in the IOS documentation's IP Application Services section.

To test that the ACLs are working correctly, open the Remote Desktop Client on CorpBox and connect to LabBox. RDP should succeed. Next, try pinging LabBox from CorpBox and vice versa. (You'll have to ping by IP address because the lab subnet doesn't yet have a DNS server.) The ping will fail because our ACLs don't permit Internet Control Message Protocol (ICMP) echo traffic. To troubleshoot the configuration on the router, you can use the commands Show Access-Lists (to view the ACL definitions) and Show IP Interface Ethernet 1 (to view the assignment of the ACLs to the interface).

Allowing Internet Access from the Lab
To allow Internet access but continue to deny all non-RDP traffic between the lab and corporate subnets, enter ACL rules C through F from Table 1 on the router. (We configured A and B in the previous steps.) Order matters, so enter them in the order shown.

The router will now let hosts on the lab subnet access the Internet, but not the corporate subnet. Because your DNS servers are probably on your corporate subnet, devices on the lab subnet won't be able to resolve domain names by using the corporate DNS servers. You can solve this problem by either configuring hosts on the lab network to use your ISP's DNS server or setting up a DNS server on the lab network.

Segregated Lab Network
Figure 8 shows how traffic flows to and from the lab network. This simple configuration isn't a true firewall and might not keep out malicious attackers. However, it will give users a sandbox environment from which they can't access your other internal networks. With this configuration, you can strictly limit access to production information systems and set up alternative systems on the lab subnet for testing, development, and general-purpose use—without worrying how they might affect your corporate systems. Best of all, your network closet probably already contains all the equipment you need.