How to protect your network when outsourcing

Outsourcing, right-sourcing, best-sourcing -- does anyone know what the latest buzzword is for this practice? No matter what the neologism is, it presents real issues that many of us in the network security field face every day.

How do we allow offshore workforces into our domestic systems securely? This seems like a simple question with a simple answer: Set up a VPN or a Web service and call it a day. I wish that was the case, because it would give me more time to improve my golf game.

But before you make a tee time, beware that there are a number of serious problems you can face that never seem to materialize until 2 a.m. the night before you go on vacation.  

The offshoring of technical jobs means that corporations need to connect their domestic network with a foreign network. Making this connection raises real security concerns.

Fear of the unknown

The foreign network represents a vast unknown. You have no idea what -- if any -- policies the partner company actually enforces, how aggressive it patches systems and what the overall state of its network is. Regardless of what is discussed in contracts, wide-open access is extremely insecure.

And because most offshore work is actually taking place in the middle of your night, if something goes wrong you get the pleasure of waking up to a BlackBerry alerting you in the wee hours of the morning.

The type of work the offshore group is contracted to do will influence how you extend your network. If the offshore group only needs to check code in and out, a full VPN would be overkill. Most major code repositories have built-in Web interfaces and username/password protection.

Your network only needs to be extended to allow the front-end Web piece to access the back-end code repository. Using the popular Concurrent Versions System (CVS) as an example, there are several free, commercial-grade Web front-ends available. By setting up a publicly available Web site, using Secure Sockets Layer and relying on the built-in username/password protection in CVS, all that is required is a public IP address and fully qualified domain name.

This is a simple solution that will let you sleep at night and play an uninterrupted round of golf on the weekend. It also applies to offshore work that doesn't require live access to your internal systems. Building on the above concepts will work for any access requirements that don't involve live, real-time access to systems.  

If the business requirements are more involved than simple code check-in and check-out, then put the clubs aside. because you are faced with a more complex problem. In my experience, management has demanded that an offshore team be completely integrated with an in-house development team and systems. This requires complete access to many systems and services. This is where things turn more complex, and there's more of a chance of exposing your network to unwanted threats.

Limit consumption

What are the services the offshore workforce will need to consume that are hosted on your local network, such as Web services, database services or Network File System services?

Looking at this with our network security hat on, these are all services being presented on the network waiting to be consumed by users. If users need to access an Oracle database, they will need to consume the SQLNet service presented by the Oracle listener, for example.

There is a good chance that users will need to consume defined services such as Secure Shell, FTP and SQLNet, as well as other nondefined services that are referenced by port numbers and not names. Compiling a complete list of host names and services is critical to a successful offshore business partner implementation.

It might seem like more work than necessary to grant access to these systems at such a granular level. But by only exposing the application ports and hosts that are required for the specific job, you prevent any other traffic coming from the offshore network into yours, regardless if the traffic is hostile or not.

Now that you have a list of resources on your network that you need to extend to the foreign network, you need to focus on how to actually get the two networks connected. Depending on the size of the offshore workforce, there are two common methods normally used to accomplish this -- implementing a LAN-to-LAN VPN tunnel or client-based VPN access. This discussion will be limited to the former.

A LAN-to-LAN VPN tunnel is a secure connection between two otherwise separate networks. To create this connection, an endpoint device is required to create termination points on both networks. A VPN endpoint can be a router, firewall, Windows server, Linux system or a dedicated VPN concentrator -- anything that can encrypt and decrypt packets at an acceptable speed.

The endpoint device acts as a gateway between the outside world and your internal network. Because the device must sit on two networks, you will have one interface that is considered "inside" (or on the local LAN) and an interface that is considered "outside"(on the Internet).

At this point, you have selected an offshore business partner, gathered a list of resources and purchased a VPN endpoint device. This is where you and the technical contact at the offshore company need to agree on the technical specifications for the VPN tunnel. Here are the common items that you both need to know to create a successful connection.

  • Endpoint IP addresses, which are the two public IP addresses that are assigned to each location's VPN device.  
  • Authentication type, which defines the packet authentication mechanism to use.
  • Encryption, which defines the encryption mechanism to use.
  • IKE Proposal, which is the Internet Key Exchange proposal.

Overlooked issues

There are several overlooked issues that come up when implementing a LAN-to-LAN solution. Name resolution, routing, latency and IP address conflicts all have the potential to keep you off the golf course.

Name resolution is something we take for granted on a local network. Normally, access to DNS servers is allowed and there are very few, if any, issues resolving a name to an IP address. For an offshore workforce that has its own internal DNS servers, name resolution for the resources/hosts that I identified earlier can be an issue. Most applications will require some form of name resolution to operate properly.

If the fully qualified domain name of your hosts is published on your Internet-accessible DNS servers, you might not have an issue at all. If this is the case, then you need to ensure that the host name resolves to the correct internal IP when a lookup is performed.

But if your network is like most, then you may have one of two issues. Either your hosts are not published on a DNS server that is accessible from the Internet, or the hosts resolve differently depending on where the lookup was performed from.

Either way, there are a few options to ensure successful name resolution. The offshore team can add the hosts and IP address associations to their local host file on each machine. A DNS zone transfer can be done between your DNS servers and the local DNS servers inside of the offshore group's network, or you can create alias records on your public-facing DNS for these hosts. More on that later.

Unavoidable latency

The next issue is more of a mental note to keep in the back of your head when management or project leads come to you and say, "All of the users offshore are reporting that the application runs extremely slow."

Trust me, it will happen about 10 minutes after the VPN connection is up. On the local network, the amount of time it takes to move a packet from one point to another is very small, less than 1 millisecond. But latency can be as high as 500 milliseconds on your offshore connection, depending on the physical location of your offshore group and the path over the Internet the packets take to get there.

I have personal experience with VPN connections from the Colorado region to Chennai, India, with latency in the 300 to 400 millisecond range. Latency at this level can and will have an impact on applications running remotely. There is nothing that can be done, short of leasing a dedicated piece of fiber between your local office and office located offshore.    

Before we cover the issue surrounding routing, security needs to be addressed. Once the tunnel has been established and before the traffic reaches your local network, the traffic should be inspected and filtered to only allow the required protocols and ports through. How this is best achieved is by placing a firewall between the "inside" interface of the VPN endpoint and your local network.

This filters traffic after it comes out of the VPN tunnel and before it reaches any part of your local network. The traffic filters are created by the list of resources you gathered, as I discussed earlier in this article. The filtering is based on IP address and port information. This firewall becomes a central chokepoint for all offshore business partner access to your network.

How do you ensure that traffic is routed correctly? Once again, there is a very good chance that you will have little if any input on the network on the offshore side. But on your local network, there are a few decisions that need to be made.

Assuming that you have not ran into the IP address conflict, the network from the foreign company will not be in your local routing table. You need to inject this network into your routing process or use static routes on the systems that the offshore group will access.  

All the traffic that will come through the VPN will traverse the firewall. All the return traffic must traverse the firewall as well. You can elect to have your firewall inject these routes or add static routes on each host to point to the firewall interface.

IP address conflicts

Your local network likely uses IP space somewhere between 10.0.0.1 and 10.255.255.254. Since there is not enough public routable IP space to go around, a private IP address allocation called RFC 1918 was enacted. The effect of this specification increases the odds of your internal network addressing and the addressing of your new offshore business partner being in the same range. As you increase your offshore business partner connections, this overlap of IP space can become a significant issue.

How do you solve the IP address conflict issue? Once the traffic is decrypted, we need to NAT this traffic before it traverses the firewall. Depending on the vendor of your VPN endpoint, the implementation will be different. All major hardware vendors support this single box VPN endpoint/NAT functionality.

Since you have complete control over your RFC 1918 address space, the best solution is to carve out a large /18 network (64/24 subnets) and use this space between the VPN endpoint and the firewall.

This simplifies the routing on your internal network. Inject a single route for the /18 network and point it to the firewall. The firewall knows about this /18 network from its local interface on that network. All the traffic that reaches your systems will appear as if it was coming from your block of RFC 1918 addresses, solving any routing or overlap issues.

I recommend carving out such a large block of IP space to have a reserve in case you contract with other offshore business partners.

There are devices that will perform the VPN piece, NAT translation and stateful inspection all in one, but I have found these devices very hard to troubleshoot when using all of the above functions and not very good at controlling access to perform different functions.

With two separate units, you isolate the VPN and NAT functions from the access controls. This also allows different people to perform these separate functions without being able to affect others. For example, there might be a junior-level admin on staff that you feel comfortable allowing to set up the VPN connection. When it comes to actually allowing traffic to traverse into your network and injecting new networks into your network, that function is sometimes best left to senior-level staff.

Attempting to troubleshoot all three of these processes in an all-in-one unit can be difficult. The access list could be failing if the NAT failed. Or you wouldn't know if the return traffic is actually being translated back or is bypassing the NAT before it's encrypted. These are normal issues that come up when trying to troubleshoot these connections. By having two separate units, it's easy to see the traffic as it traverses the firewall and the VPN endpoint.

Hopefully, this overview of some of the issues and concerns surrounding the extension of your corporate network will help you make it out to the golf course one sunny day.

Shane Blandford has over 10 years of experience in computer networking, security and development. He currently lives and works in Denver. He can be reached at shane.blandford@gmail.com >

6 tips for scaling up team collaboration tools
  
Shop Tech Products at Amazon